Excel vs SQL: trade-offs và khi nào dùng cái nào

Mở đầu — vì sao bài này quan trọng

Nếu bạn đang làm Business Analyst (BA) tại Việt Nam, gần như chắc chắn bạn đã quá quen thuộc với Excel. Excel là công cụ "quốc dân" — từ kế toán, sales, marketing đến vận hành, ai cũng dùng. Và khi bạn bắt đầu học SQL, một câu hỏi rất tự nhiên sẽ xuất hiện trong đầu: "Vậy giữa Excel và SQL, khi nào tôi nên dùng cái nào? Học SQL rồi có phải bỏ Excel không?"

Câu trả lời ngắn gọn: Không bỏ Excel, và cũng không thần thánh hóa SQL. Đây không phải cuộc chiến một mất một còn. Một BA giỏi là người biết chọn đúng công cụ cho đúng việc — giống như một người thợ biết khi nào dùng búa, khi nào dùng tua vít.

Bài học này không dạy bạn cú pháp mới. Thay vào đó, nó dạy bạn một kỹ năng tư duy mà rất nhiều BA thiếu: khả năng đánh giá trade-off (sự đánh đổi) giữa hai công cụ và ra quyết định nhanh, đúng. Đây chính là thứ phân biệt một BA "biết chạy query" với một BA "biết khi nào nên chạy query, khi nào nên mở Excel". Khi bạn nắm vững điều này, bạn sẽ tiết kiệm được hàng giờ làm việc mỗi tuần, tránh được những sai lầm tốn kém, và quan trọng nhất là biết cách giải thích lựa chọn của mình cho sếp và đồng nghiệp.

Khái niệm cốt lõi

Trước khi so sánh, hãy hiểu bản chất của hai công cụ này. Chúng được sinh ra để giải quyết những bài toán khác nhau.

Excel là gì về bản chất

Excel là một bảng tính (spreadsheet) — một lưới ô (cell) nơi bạn có thể nhập dữ liệu, công thức, và xem kết quả trực quan ngay lập tức. Điểm mạnh cốt lõi của Excel nằm ở chữ "trực quan và tương tác": bạn nhìn thấy từng con số, sửa trực tiếp, kéo công thức, vẽ biểu đồ chỉ trong vài cú click. Dữ liệu và logic xử lý nằm chung một chỗ, ngay trước mắt bạn.

SQL là gì về bản chất

SQL (Structured Query Language) là một ngôn ngữ truy vấn dùng để lấy và xử lý dữ liệu từ cơ sở dữ liệu (database). Điểm mạnh cốt lõi của SQL nằm ở chữ "quy mô và lặp lại": nó được thiết kế để xử lý hàng triệu, hàng chục triệu dòng dữ liệu một cách nhất quán, và mỗi truy vấn bạn viết ra là một logic có thể chạy lại bất cứ lúc nào với kết quả y hệt.

Bảng so sánh trade-off cốt lõi

Hãy ghi nhớ bảng dưới đây — nó là "kim chỉ nam" giúp bạn quyết định nhanh:

Vì sao Excel "đuối" khi dữ liệu lớn

Excel có giới hạn kỹ thuật cứng: tối đa 1.048.576 dòng mỗi sheet. Nhưng thực tế, bạn sẽ "đụng tường" sớm hơn rất nhiều. Khi file vượt khoảng 100.000–200.000 dòng kèm nhiều công thức, Excel bắt đầu chậm: mở file mất vài phút, mỗi lần sửa một ô là máy "treo" để tính lại toàn bộ, file phình lên hàng trăm MB. Đây không phải lỗi của bạn — đó là bản chất Excel tính toán mọi thứ trong bộ nhớ (in-memory) trên máy cá nhân.

Vì sao SQL "đuối" khi cần trực quan và tức thời

Ngược lại, SQL không có khả năng vẽ biểu đồ hay định dạng màu sắc. Khi bạn muốn "thử nghịch" dữ liệu — kéo một cột sang trái, tô màu ô lớn hơn 1 triệu, thêm nhanh một dòng giả định để xem kết quả — SQL bắt bạn viết lại query, chạy lại, rồi đọc kết quả dạng bảng thô. Với những phân tích nhỏ, mang tính "động não", vòng lặp này chậm và gò bó hơn Excel nhiều.

Nguyên tắc vàng để ghi nhớ

> SQL để LẤY và CHUẨN HÓA dữ liệu ở quy mô lớn. Excel để KHÁM PHÁ, TRÌNH BÀY và CHIA SẺ kết quả cuối.

Trong thực tế, hai công cụ này thường bổ trợ nhau chứ không loại trừ nhau. Quy trình phổ biến của một BA chuyên nghiệp là: dùng SQL để rút gọn 5 triệu dòng dữ liệu thô xuống còn một bảng tổng hợp 2.000 dòng, rồi xuất bảng đó ra Excel để vẽ chart và làm slide trình bày cho sếp. Đây gọi là quy trình "SQL trước, Excel sau".

Tình huống thực tế

Tình huống 1: BA tại sàn thương mại điện tử kiểu Tiki — khi Excel "chết đứng"

Chị Lan là BA tại một sàn thương mại điện tử lớn ở TP.HCM. Sếp yêu cầu: "Phân tích doanh thu theo danh mục sản phẩm trong 6 tháng qua." Phản xạ đầu tiên của chị Lan là xuất dữ liệu đơn hàng ra Excel.

Vấn đề: bảng orders của 6 tháng có 8,4 triệu dòng. Khi chị thử export, hệ thống chỉ cho ra tối đa 1 triệu dòng — đã mất dữ liệu. Chị thử chia nhỏ thành nhiều file theo tháng, nhưng mỗi file 1,4 triệu dòng làm Excel của chị (laptop 8GB RAM) treo cứng mỗi khi thêm cột tính toán. Một buổi sáng trôi qua mà chị mới chỉ "vật lộn" được với dữ liệu của một tháng.

Cách làm đúng: Thay vì kéo toàn bộ dữ liệu thô về máy, chị Lan viết một câu SQL để database tự tổng hợp:

SELECT category, 
       DATE_FORMAT(order_date, '%Y-%m') AS thang,
       SUM(amount) AS doanh_thu,
       COUNT(*) AS so_don
FROM orders
WHERE order_date >= '2025-12-01'
GROUP BY category, DATE_FORMAT(order_date, '%Y-%m');

Kết quả trả về chỉ khoảng 180 dòng (30 danh mục × 6 tháng). Chị copy 180 dòng này vào Excel, vẽ pivot chart trong 5 phút, làm slide xong trước giờ ăn trưa.

Bài học rút ra: Khi dữ liệu nguồn quá lớn, đừng cố mang "cả tảng băng" về Excel. Hãy để SQL làm việc nặng (tổng hợp ở phía server), chỉ mang về phần "ngọn" đã được nén lại. 8,4 triệu dòng → 180 dòng là sự khác biệt giữa "treo máy cả buổi" và "xong trước trưa".

Tình huống 2: BA marketing tại startup fintech — khi Excel lại là lựa chọn đúng

Anh Tuấn là BA tại một ví điện tử kiểu MoMo. Trưởng nhóm marketing nhờ anh gấp: "Mình vừa chạy thử một chiến dịch khuyến mãi nhỏ cho 3.500 khách hàng VIP. Em xem nhanh nhóm nào phản hồi tốt nhất, trong 30 phút nữa họp."

Anh Tuấn có một file CSV 3.500 dòng do team marketing tự export từ công cụ gửi tin. Đây là dữ liệu rời rạc, không nằm trong database chính, và yêu cầu mang tính khám phá nhanh, một lần (ad-hoc).

Trong tình huống này, nếu anh Tuấn khăng khăng dùng SQL — phải xin import file vào database, xin quyền tạo bảng, viết query — anh sẽ trễ họp. Thay vào đó, anh mở thẳng file CSV bằng Excel, dùng pivot table kéo-thả trong 10 phút: nhóm khách theo độ tuổi, theo tỉnh thành, tính tỷ lệ mở khuyến mãi. Anh phát hiện nhóm 25–34 tuổi ở Hà Nội có tỷ lệ phản hồi cao gấp đôi, tô màu nổi bật, chụp màn hình đưa vào nhóm chat trước giờ họp.

Bài học rút ra: Khi dữ liệu nhỏ (vài nghìn dòng), nằm rời ngoài database, và bạn cần câu trả lời "nhanh và bẩn" (quick and dirty) trong vài chục phút — Excel thắng tuyệt đối. Việc đưa nó vào SQL sẽ là "dùng đại bác bắn chim sẻ", tốn thời gian setup hơn cả thời gian phân tích.

Tình huống 3: Báo cáo định kỳ hàng tuần — khi "lặp lại" quyết định tất cả

Chị Hương là BA vận hành tại một công ty giao vận kiểu Grab/Be. Mỗi sáng thứ Hai, chị phải nộp báo cáo: số chuyến, tỷ lệ hủy, thời gian chờ trung bình theo từng quận. Lúc đầu, chị làm hoàn toàn bằng Excel: export dữ liệu tuần, copy vào file mẫu, kéo công thức, cập nhật pivot.

Vấn đề xuất hiện sau vài tuần: mỗi lần làm là một lần có nguy cơ sai. Có tuần chị quên cập nhật vùng dữ liệu của pivot nên thiếu mất 2 ngày cuối; có tuần chị paste nhầm cột làm tỷ lệ hủy sai lệch, suýt báo cáo sai cho ban giám đốc. Mỗi báo cáo "thủ công" tốn 90 phút và đầy rủi ro thao tác tay.

Cách làm đúng: Chị Hương viết một câu SQL cố định cho toàn bộ logic báo cáo, chỉ cần đổi tham số ngày là chạy lại được kết quả nhất quán tuyệt đối. Mỗi sáng thứ Hai, chị chỉ chạy query, lấy kết quả đổ vào file Excel mẫu đã dựng sẵn chart. Thời gian giảm từ 90 phút xuống còn 15 phút, và quan trọng hơn: không còn sai số do thao tác tay.

Bài học rút ra: Bất kỳ công việc nào bạn phải lặp đi lặp lại (báo cáo hàng ngày/tuần/tháng) đều là tín hiệu mạnh nên chuyển logic sang SQL. Excel làm tốt việc "một lần", nhưng "làm đi làm lại" là điểm yếu chí mạng của nó — vì mỗi lần lặp là một lần con người có thể sai.

Hướng dẫn từng bước

Đây là khung quyết định (decision framework) bạn có thể áp dụng mỗi khi nhận một yêu cầu phân tích. Hãy tự hỏi lần lượt 5 câu sau:

Bước 1 — Dữ liệu lớn cỡ nào? Ước lượng số dòng. Nếu dưới ~100.000 dòng → Excel xử lý thoải mái. Nếu trên ngưỡng đó, hoặc bạn không chắc → nghiêng về SQL để tổng hợp trước.

Bước 2 — Dữ liệu nằm ở đâu? Nếu dữ liệu đã nằm trong database công ty → SQL là cửa ngõ tự nhiên. Nếu là file CSV/Excel rời người ta gửi cho bạn → mở bằng Excel cho nhanh, trừ khi cần ghép với dữ liệu trong DB.

Bước 3 — Công việc này làm một lần hay lặp lại? Một lần, ad-hoc → Excel ưu tiên. Lặp lại định kỳ (báo cáo tuần/tháng) → viết SQL để tái sử dụng và tránh sai số.

Bước 4 — Có cần ghép nhiều nguồn dữ liệu không? Cần JOIN nhiều bảng (đơn hàng + khách hàng + sản phẩm) → SQL làm việc này gọn gàng. Chỉ một bảng phẳng đơn giản → Excel đủ dùng.

Bước 5 — Đầu ra cuối cùng là gì? Cần biểu đồ đẹp, slide trình bày, file gửi cho người không biết SQL → kết thúc ở Excel (hoặc công cụ BI). Cần một bảng dữ liệu sạch để feed sang hệ thống khác → dừng ở SQL.

Áp dụng quy trình kết hợp "SQL trước, Excel sau":

• Dùng SQL để lọc, JOIN, GROUP BY và rút gọn dữ liệu lớn xuống một bảng tổng hợp nhỏ.
• Export kết quả (CSV hoặc copy trực tiếp) sang Excel.
• Trong Excel, dùng pivot table, chart, conditional formatting để khám phá và trình bày.
• Lưu câu SQL lại để lần sau chạy lại — đừng để nó "bay" mất.

Lỗi thường gặp & mẹo

Lỗi 1: Kéo toàn bộ dữ liệu thô về Excel rồi mới lọc. Đây là sai lầm phổ biến nhất. Nhiều bạn export cả triệu dòng về rồi mới dùng filter trong Excel. Hãy lọc và tổng hợp NGAY trong SQL (WHERE, GROUP BY) trước khi mang về — database mạnh hơn laptop của bạn rất nhiều.

Lỗi 2: Nghĩ rằng học SQL là phải bỏ Excel. Sai hoàn toàn. BA giỏi nhất dùng cả hai. SQL không thay thế khả năng pivot, chart, làm slide của Excel. Hãy xem chúng là một cặp đôi ăn ý.

Lỗi 3: Dùng Excel cho báo cáo lặp lại rồi sai số thao tác tay. Mỗi lần copy-paste, kéo công thức là một cơ hội để lỗi xuất hiện. Nếu bạn làm cùng một báo cáo lần thứ ba, đó là tín hiệu nên chuyển logic sang SQL.

Lỗi 4: Tin tưởng tuyệt đối vào con số trong Excel mà không kiểm tra. Excel rất dễ "âm thầm" sai: pivot quên cập nhật vùng dữ liệu, công thức bị đứt khi chèn dòng, định dạng số nhầm dấu phẩy/dấu chấm (vấn đề rất hay gặp với dữ liệu tiền tệ VND). Luôn đối chiếu một vài con số tổng với nguồn.

Mẹo 1: Khi không chắc dữ liệu lớn cỡ nào, hãy chạy SELECT COUNT(*) FROM bang trước. Một câu lệnh đơn giản này giúp bạn quyết định ngay nên dùng công cụ nào.

Mẹo 2: Học thêm Power Query trong Excel — nó là "cầu nối" tuyệt vời, cho phép Excel kết nối trực tiếp vào database và làm một số phép biến đổi kiểu SQL, giúp tự động hóa bước refresh dữ liệu.

Mẹo 3: Khi gửi báo cáo cho sếp, đừng gửi file Excel hàng trăm MB. Hãy gửi bản đã rút gọn, sạch, có chart — phần dữ liệu thô để lại trong SQL.

Bài tập thực hành

• Phân loại tình huống: Với mỗi yêu cầu sau, hãy quyết định nên dùng Excel, SQL, hay kết hợp cả hai, và viết một câu giải thích lý do:

- (a) Sếp gửi file CSV 4.000 dòng khảo sát khách hàng, cần phân tích nhanh trong giờ tới. - (b) Báo cáo doanh thu hàng ngày từ bảng giao dịch 12 triệu dòng. - (c) Phân tích một lần mối quan hệ giữa 3 bảng: khách hàng, đơn hàng, sản phẩm trong DB. - (d) Làm slide trình bày kết quả cho ban giám đốc.

• Tự đánh giá công việc của bạn: Liệt kê 3 công việc phân tích bạn (hoặc team bạn) đang làm bằng Excel hiện tại. Với mỗi việc, áp dụng khung 5 câu hỏi ở phần "Hướng dẫn từng bước" để xác định: có nên chuyển sang SQL không? Vì sao?

• Thiết kế quy trình kết hợp: Giả sử bạn cần báo cáo top 20 sản phẩm bán chạy mỗi tháng từ một bảng đơn hàng 5 triệu dòng. Hãy mô tả bằng lời (không cần code hoàn chỉnh): bước nào làm bằng SQL, dữ liệu rút gọn còn bao nhiêu dòng, và bước nào làm bằng Excel.

Tóm tắt

Excel và SQL không phải đối thủ — chúng là một cặp công cụ bổ trợ, mỗi cái mạnh ở một mặt trận. Excel thắng khi dữ liệu nhỏ (dưới ~100.000 dòng), khi bạn cần khám phá ad-hoc nhanh, khi cần trực quan hóa bằng pivot/chart, và khi cần chia sẻ file cho người không biết database. SQL thắng khi dữ liệu lớn, khi cần ghép nhiều bảng, và đặc biệt khi công việc phải lặp lại nhiều lần — vì nó cho kết quả nhất quán, không sai số thao tác tay.

Quy tắc vàng cần khắc cốt ghi tâm: SQL để lấy và chuẩn hóa dữ liệu ở quy mô lớn; Excel để khám phá, trình bày và chia sẻ kết quả cuối. Quy trình "SQL trước, Excel sau" — rút gọn dữ liệu lớn bằng SQL rồi đưa phần ngọn sang Excel để vẽ chart — là cách làm việc của những BA chuyên nghiệp nhất.

Và đừng quên khung 5 câu hỏi: dữ liệu lớn cỡ nào, nằm ở đâu, làm một lần hay lặp lại, có cần JOIN nhiều bảng không, và đầu ra cuối là gì. Trả lời được năm câu này, bạn sẽ luôn chọn đúng công cụ — đó mới là dấu hiệu của một BA thực thụ.