Để AI viết câu SQL đúng cho ứng dụng của bạn, hãy đưa cho nó cấu trúc các bảng liên quan (tên cột, kiểu, khoá, quan hệ), tên và phiên bản hệ quản trị cơ sở dữ liệu, câu hỏi nghiệp vụ bằng lời, và vài dòng dữ liệu giả kèm kết quả mong đợi. Không đưa dữ liệu thật. Rồi chạy câu nhận về trên dữ liệu thử, đọc kế hoạch thực thi, trước khi đặt nó vào mã.
Bài này dành cho lập trình viên viết truy vấn trong ứng dụng, không phải bài nhập môn SQL cho dân văn phòng. Nội dung gồm mẫu câu lệnh, những bẫy kinh điển mà câu SQL do AI viết hay vấp — JOIN nhân dòng, NULL, nhóm theo cột, khoảng thời gian — cách kiểm hiệu năng, và quy trình riêng cho câu lệnh sửa hoặc xoá dữ liệu.
Đưa lược đồ, không đưa dữ liệu
Trợ lý AI không nhìn thấy cơ sở dữ liệu của bạn, trừ khi bạn dùng một công cụ được cấp quyền kết nối trực tiếp — và trong phần lớn trường hợp bạn không nên cấp quyền đó cho cơ sở dữ liệu thật. Không có lược đồ, nó sẽ đoán tên bảng và tên cột theo kiểu phổ biến: users, orders, created_at. Nếu bảng của bạn tên là don_hang với cột tao_luc, câu nhận về sẽ chạy lỗi, hoặc tệ hơn, chạy được trên một bảng khác cùng tên.
Thứ cần đưa là câu tạo bảng hoặc kết quả lệnh mô tả bảng, cho đúng những bảng mà câu truy vấn chạm tới. Thêm một dòng về quan hệ: một khách có nhiều đơn hàng, một đơn có nhiều dòng hàng. Nếu có ràng buộc nghiệp vụ không thể hiện trong lược đồ, như đơn đã huỷ vẫn nằm trong bảng với trạng thái riêng, nói rõ, vì đó là loại chi tiết làm số liệu sai mà không báo lỗi.
Dữ liệu thật của khách — tên, số điện thoại, địa chỉ, lịch sử mua — không cần cho việc viết truy vấn. Tạo năm đến mười dòng giả có cùng hình dạng, bao gồm cả trường hợp khó như khách chưa có đơn nào, đơn có trường để trống. Bộ dữ liệu giả này cũng là thứ bạn dùng để kiểm câu nhận về.
Mẫu câu lệnh viết truy vấn
Bài toán ví dụ giả định: báo cáo số đơn và tổng tiền theo từng khách trong tháng trước, cho một cửa hàng đồ gia dụng.
- "Hệ quản trị: [MySQL 8.0 / PostgreSQL 16 / MariaDB 10.11]."
- "Lược đồ: [dán câu tạo bảng khach_hang và don_hang]. Quan hệ: một khách nhiều đơn. Đơn có cột trang_thai, giá trị huy là đơn đã huỷ."
- "Câu hỏi: với mỗi khách, số đơn không huỷ và tổng tiền trong tháng trước. Khách không có đơn nào vẫn phải hiện với số 0."
- "Dữ liệu thử: [dán năm dòng mỗi bảng]. Kết quả mong đợi: [dán bảng kết quả]."
- "Viết câu truy vấn, giải thích từng mệnh đề bằng một dòng, nêu chỉ mục nào nên có để câu chạy nhanh trên bảng lớn. Giá trị lọc thời gian đưa vào bằng tham số, không ghép chuỗi."
Câu "khách không có đơn vẫn phải hiện với số 0" là một ca biên được nói thẳng ra. Thiếu nó, trợ lý có thể viết JOIN thường và khách không mua gì trong tháng biến mất khỏi báo cáo — một sai lệch mà người đọc báo cáo không có cách nào phát hiện.
Câu hỏi nghiệp vụ mơ hồ là nguồn sai lớn nhất
Phần lớn câu SQL "sai" do AI viết thực ra trả lời đúng một câu hỏi khác với câu bạn có trong đầu. Yêu cầu "lấy danh sách khách VIP" buộc trợ lý tự định nghĩa VIP: tổng chi tiêu lớn, mua nhiều lần, hay có cờ đánh dấu trong bảng khách. Nó sẽ chọn một cách, viết rất gọn, và báo cáo ra đời với định nghĩa mà phòng kinh doanh chưa từng đồng ý.
Sửa bằng cách viết định nghĩa thành câu đo được: "Khách VIP là khách có tổng tiền các đơn đã giao, không tính đơn huỷ và đơn trả hàng, trong mười hai tháng gần nhất tính tới ngày chạy báo cáo, từ mức [ngưỡng giả định] trở lên." Mỗi cụm trong câu đó — đã giao, không tính huỷ, không tính trả, mười hai tháng, tính tới ngày chạy — là một quyết định mà nếu bỏ trống, trợ lý sẽ quyết thay bạn.
Nếu chính bạn chưa có định nghĩa, hỏi trợ lý liệt kê các cách định nghĩa khả dĩ và hệ quả của từng cách, rồi mang danh sách đó đi hỏi người đặt yêu cầu báo cáo. Viết câu SQL là việc cuối cùng, sau khi định nghĩa đã được chốt.
Những bẫy SQL kinh điển mà câu AI viết hay vấp
Các bẫy dưới đây đều tạo ra kết quả sai mà không có lỗi cú pháp. Đọc câu nhận về với danh sách này trong đầu.
| Bẫy | Biểu hiện | Cách bắt |
|---|---|---|
| JOIN nhân dòng | Nối khách với đơn và với dòng hàng cùng lúc, tổng tiền bị cộng lặp | So tổng tiền với một câu đơn giản chỉ trên bảng đơn hàng |
| LEFT JOIN thành JOIN thường | Điều kiện lọc bảng bên phải đặt ở WHERE làm mất các dòng không khớp | Đưa điều kiện đó vào mệnh đề ON; kiểm khách không có đơn còn hiện không |
| COUNT(*) với LEFT JOIN | Khách không có đơn bị đếm là 1 đơn | Đếm theo cột khoá của bảng bên phải, ví dụ COUNT(d.id) |
| NOT IN gặp NULL | Danh sách con có một giá trị NULL làm cả điều kiện không trả dòng nào | Dùng NOT EXISTS hoặc lọc NULL trong danh sách con |
| Khoảng thời gian | Dùng BETWEEN với cột ngày giờ làm sót dữ liệu của ngày cuối | Dùng mốc lớn hơn hoặc bằng ngày đầu và nhỏ hơn ngày đầu kỳ sau |
| Nhóm theo cột | Chọn cột không nằm trong GROUP BY; có hệ quản trị báo lỗi, có cái trả giá trị bất kỳ | Yêu cầu mọi cột không tổng hợp đều nằm trong GROUP BY |
Bộ dữ liệu giả có ý đồ là cách bắt các bẫy này nhanh nhất: một khách không có đơn, một đơn có hai dòng hàng, một đơn đã huỷ, một đơn lúc 23 giờ ngày cuối tháng, một giá trị để trống. Năm dòng đó phủ được gần hết danh sách trên.
Bắt trợ lý giải thích, rồi tự chạy tay một dòng
Lời giải thích từng mệnh đề không chỉ để bạn hiểu; nó là nơi lộ ra cách trợ lý hiểu đề. Nếu nó viết "lọc các đơn có trạng thái khác huy" ở mệnh đề WHERE trong khi bạn dùng LEFT JOIN, bạn đã có lý do để nghi ngờ: điều kiện đó đặt ở WHERE sẽ loại khách không có đơn. Đọc lời giải thích chậm hơn đọc mã một chút nhưng dễ thấy lỗi logic hơn nhiều.
Sau đó chọn một khách trong dữ liệu giả và tự tính tay kết quả cho khách đó: đếm đơn, cộng tiền, loại đơn huỷ. So với dòng tương ứng trong kết quả truy vấn. Nếu khớp, thử thêm khách không có đơn. Hai lần so tay mất vài phút nhưng bắt được phần lớn lỗi logic mà mắt đọc bỏ qua.
Với truy vấn phức tạp, có thể yêu cầu trợ lý viết lại theo từng bước bằng biểu thức bảng chung — mệnh đề WITH — mỗi bước một tên. Mỗi bước chạy riêng được, nên bạn kiểm từng tầng thay vì đối mặt với một câu lồng ba lớp.
Kiểm hiệu năng trước khi đặt vào mã
Đọc kế hoạch thực thi. Chạy câu truy vấn với EXPLAIN đặt phía trước, có trong cả MySQL, MariaDB và PostgreSQL, để xem hệ quản trị định quét toàn bảng hay dùng chỉ mục. Kết quả của EXPLAIN khó đọc lúc đầu; có thể dán kết quả, không kèm dữ liệu, cho trợ lý giải thích.
Thử trên dữ liệu có kích thước gần thật. Câu chạy tức thì với mười dòng có thể mất hàng chục giây với vài triệu dòng. Nếu có môi trường thử với bản sao đã che dữ liệu, chạy ở đó.
Đừng thêm chỉ mục chỉ vì AI đề xuất. Mỗi chỉ mục làm thao tác ghi chậm hơn và tốn chỗ. Hỏi trợ lý những truy vấn nào khác cũng được lợi từ chỉ mục đó, và cân nhắc cùng người phụ trách cơ sở dữ liệu.
Hàm bọc cột làm mất chỉ mục. Điều kiện kiểu áp hàm lấy tháng lên cột ngày rồi so sánh thường không dùng được chỉ mục trên cột đó. Yêu cầu viết lại thành khoảng giá trị trên chính cột gốc.
Câu UPDATE và DELETE: quy trình riêng
Câu đọc dữ liệu sai thì ra báo cáo sai; câu sửa hoặc xoá sai thì mất dữ liệu. Với loại câu này, thêm các bước sau dù trợ lý viết trông đúng tới đâu:
- Yêu cầu trợ lý viết kèm một câu SELECT có cùng điều kiện WHERE, để xem trước những dòng sẽ bị ảnh hưởng.
- Chạy câu SELECT đó, đếm số dòng, nhìn vài dòng mẫu xem có đúng những dòng bạn định sửa không.
- Sao lưu bảng hoặc ít nhất các dòng bị ảnh hưởng trước khi chạy.
- Chạy trong giao dịch nếu hệ quản trị và loại bảng hỗ trợ: bắt đầu giao dịch, chạy câu sửa, kiểm lại số dòng, rồi mới xác nhận hoặc huỷ.
- Không để tác tử AI tự chạy câu sửa hay xoá trên cơ sở dữ liệu thật. Nó chỉ đưa câu; người chạy là bạn.
Một câu DELETE thiếu WHERE hoặc có WHERE sai một ký tự là loại sự cố mà công cụ nào cũng không cứu được nếu không có bản sao lưu. Trợ lý viết câu rất nhanh, và chính tốc độ đó dễ làm người dùng bỏ qua bước chậm lại.
Đưa câu SQL vào mã ứng dụng
Câu chạy đúng trong công cụ quản trị chưa phải là câu đúng trong ứng dụng. Khi chuyển vào mã, mọi giá trị đến từ người dùng — ô tìm kiếm, tham số trên đường dẫn, mốc thời gian — phải đi qua truy vấn có tham số của thư viện kết nối, không ghép trực tiếp vào chuỗi SQL. Trợ lý đôi khi viết bản ghép chuỗi cho gọn khi minh hoạ; nếu bạn đã dặn từ đầu như trong mẫu câu lệnh, kiểm lại xem nó có giữ lời không.
Ghép chuỗi là cửa mở cho tấn công chèn SQL, một trong những lỗi bảo mật cũ nhất và vẫn phổ biến nhất trong mã viết vội. Phần phòng thủ chi tiết có ở danh mục an toàn mã nguồn của trang. Ở bước giao việc, chỉ cần một dòng ràng buộc trong câu lệnh và một lần đọc lại khi nhận mã.
Câu hỏi thường gặp
Có nên cho AI kết nối thẳng vào cơ sở dữ liệu để tự viết và chạy truy vấn không?
Với cơ sở dữ liệu thật thì không nên, nhất là với quyền ghi. Nếu công cụ hỗ trợ kết nối, chỉ cho phép trên bản sao đã che dữ liệu, bằng tài khoản chỉ đọc. Ngay cả khi chỉ đọc, truy vấn nặng cũng có thể làm chậm hệ thống đang phục vụ khách.
Câu SQL viết cho MySQL có chạy được trên PostgreSQL không?
Câu đơn giản thường chạy được, nhưng có khác biệt ở hàm xử lý ngày, cách trích dẫn tên, so sánh chuỗi có phân biệt hoa thường, và cú pháp chèn hoặc cập nhật khi trùng khoá. Luôn nói rõ hệ quản trị và phiên bản trong câu lệnh, và chạy thử trên đúng hệ đó.
Làm sao biết câu truy vấn AI đề xuất đã tối ưu chưa?
Không có câu trả lời tuyệt đối. Đọc EXPLAIN xem có quét toàn bảng lớn không, đo thời gian trên dữ liệu kích thước gần thật, và hỏi trợ lý hai cách viết khác nhau rồi so. Với câu chạy rất thường xuyên, nhờ người có kinh nghiệm với hệ quản trị đó xem lại.
AI viết truy vấn dùng thủ tục lưu trữ hay trigger, có nên dùng không?
Tuỳ quy ước của dự án. Thủ tục lưu trữ và trigger đặt logic vào cơ sở dữ liệu, khó thấy hơn khi đọc mã ứng dụng và khó kiểm thử hơn. Nếu dự án chưa dùng, yêu cầu trợ lý giải quyết bằng truy vấn thường trong mã trước, và chỉ dùng khi có lý do rõ ràng.
Có nên nhờ AI viết câu chuyển đổi lược đồ, như thêm cột hay đổi kiểu cột không?
Có thể, nhưng đó là loại câu cần cẩn trọng như UPDATE. Hỏi thêm: câu này có khoá bảng lâu không trên bảng lớn, dữ liệu cũ được xử lý thế nào, và câu quay lui là gì. Chạy trên bản sao trước, và chọn giờ ít người dùng.