Cách dùng Vibe Coding để tạo và tối ưu câu lệnh SQL
Bùi Tấn Lực - 104
- 12/10/2026
SQL thường không khó ở việc nhớ cú pháp, mà khó ở chỗ biến một yêu cầu nghiệp vụ thành truy vấn vừa đúng dữ liệu, vừa dễ bảo trì và đủ nhanh khi hệ thống lớn dần. Đây cũng là điểm mà Vibe Coding có thể hỗ trợ rất tốt nếu biết cách đặt yêu cầu và kiểm soát kết quả.
Thay vì tự viết từng câu lệnh từ đầu, lập trình viên có thể mô tả mục tiêu bằng ngôn ngữ tự nhiên, cung cấp cấu trúc database và để AI đề xuất truy vấn. Sau đó, người viết code kiểm tra logic, dữ liệu đầu vào, hiệu năng và chỉnh sửa truy vấn trước khi đưa vào website hoặc ứng dụng thực tế.
Điểm quan trọng là Vibe Coding không đồng nghĩa với việc giao toàn bộ việc viết SQL cho AI. Cách làm hiệu quả hơn là dùng AI như một cộng sự chuyên hỗ trợ tạo bản nháp, phân tích truy vấn, tìm điểm bất hợp lý và đề xuất hướng tối ưu.
Vibe Coding với SQL là gì?
Vibe Coding là cách phát triển phần mềm trong đó lập trình viên mô tả điều mình muốn đạt được bằng ngôn ngữ tự nhiên, sau đó sử dụng AI để chuyển yêu cầu đó thành code có thể chạy được. Với SQL, phương pháp này đặc biệt phù hợp với những công việc như tạo truy vấn SELECT, viết JOIN, lọc dữ liệu, tổng hợp báo cáo, tạo câu lệnh UPDATE hoặc phân tích một truy vấn đang chạy chậm.
Ví dụ, thay vì bắt đầu bằng việc tự viết:
SELECT ...
có thể mô tả yêu cầu rõ ràng hơn:
Cho tôi danh sách 20 khách hàng có tổng giá trị đơn hàng cao nhất trong 90 ngày gần đây. Chỉ tính các đơn hàng có trạng thái đã thanh toán. Hiển thị tên khách hàng, số đơn hàng và tổng tiền, sắp xếp tổng tiền giảm dần.
AI có thể dựa trên yêu cầu đó để đề xuất câu SQL. Tuy nhiên, kết quả chỉ đáng tin cậy khi AI biết cấu trúc bảng, tên cột, quan hệ giữa các bảng và quy tắc nghiệp vụ liên quan.
Vì vậy, phần quan trọng nhất của Vibe Coding không phải là viết một câu lệnh thật nhanh mà là mô tả đúng vấn đề trước khi yêu cầu AI tạo SQL.
Vì sao SQL rất phù hợp với cách làm này?
SQL có cú pháp tương đối rõ ràng và phần lớn truy vấn đều có thể mô tả bằng mục tiêu nghiệp vụ. Điều này giúp AI dễ chuyển một yêu cầu bằng ngôn ngữ tự nhiên thành cấu trúc truy vấn.
Chẳng hạn, một yêu cầu như “lấy sản phẩm bán chạy nhất trong tháng” có thể được phân tích thành nhiều thành phần:
- Xác định bảng sản phẩm.
- Xác định bảng đơn hàng hoặc chi tiết đơn hàng.
- Xác định khoảng thời gian cần thống kê.
- Xác định trạng thái đơn hàng được tính.
- Tính tổng số lượng bán.
- Nhóm dữ liệu theo sản phẩm.
- Sắp xếp theo số lượng giảm dần.
- Giới hạn số kết quả trả về.
AI có thể giúp chuyển toàn bộ quá trình này thành SQL nhanh hơn so với việc viết thủ công. Nhưng nếu yêu cầu ban đầu bỏ sót điều kiện “chỉ tính đơn đã thanh toán”, truy vấn được tạo ra có thể vẫn chạy bình thường nhưng trả về kết quả sai.
Đây là điểm cần đặc biệt lưu ý: SQL sai logic thường nguy hiểm hơn SQL báo lỗi cú pháp. Một truy vấn lỗi cú pháp có thể được phát hiện ngay, trong khi truy vấn trả về số liệu sai có thể tồn tại rất lâu trước khi có người nhận ra.
Cần cung cấp gì cho AI trước khi tạo truy vấn?
Muốn Vibe Coding tạo SQL chính xác, không nên chỉ đưa một câu yêu cầu ngắn như “viết SQL lấy danh sách khách hàng”. AI cần đủ ngữ cảnh để hiểu dữ liệu đang được tổ chức như thế nào.
Cấu trúc các bảng liên quan
Hãy cung cấp tên bảng và những cột thực sự liên quan. Không nhất thiết phải đưa toàn bộ database nếu truy vấn chỉ sử dụng một vài bảng.
customers
- id
- name
- email
- created_at
orders
- id
- customer_id
- total_amount
- status
- created_at
Cách cung cấp này giúp AI hiểu được mối quan hệ cơ bản giữa customers.id và orders.customer_id.
Quan hệ giữa các bảng
Nếu có nhiều bảng, nên nói rõ khóa liên kết. Ví dụ:
customers.id = orders.customer_id
Nếu database có khóa ngoại, bảng trung gian hoặc quan hệ nhiều-nhiều, cũng nên mô tả ngay từ đầu. Điều này hạn chế tình trạng AI tự đoán quan hệ và tạo JOIN không đúng.
Quy tắc nghiệp vụ
Đây là phần thường bị bỏ quên nhưng lại ảnh hưởng trực tiếp đến độ chính xác của kết quả.
Ví dụ, nếu website có các trạng thái đơn hàng gồm pending, paid, cancelled và refunded, hãy nói rõ trạng thái nào được tính vào doanh thu.
Chỉ tính đơn hàng có status = 'paid'.
Không tính đơn pending, cancelled hoặc refunded.
AI khi đó có cơ sở để đưa điều kiện nghiệp vụ vào truy vấn thay vì tự suy đoán.
Kết quả đầu ra mong muốn
Đừng chỉ nói “tạo SQL lấy khách hàng”. Hãy mô tả chính xác dữ liệu cần nhận được.
Ví dụ:
Cần trả về:
- customer_id
- customer_name
- total_orders
- total_spent
Sắp xếp total_spent giảm dần và chỉ lấy 20 khách hàng đầu tiên.
Yêu cầu càng cụ thể thì truy vấn được tạo ra càng ít phải sửa lại.
Cách viết prompt để AI tạo SQL chính xác hơn
Một prompt tốt cho SQL nên có cấu trúc gần giống một bản mô tả kỹ thuật ngắn. Có thể bắt đầu bằng mục tiêu, sau đó cung cấp schema, quy tắc nghiệp vụ, kết quả mong muốn và các giới hạn cần tuân thủ.
Một mẫu prompt có thể viết như sau:
Tôi đang sử dụng MySQL.
Mục tiêu:
Lấy 20 khách hàng có tổng giá trị đơn hàng cao nhất trong 90 ngày gần đây.
Schema:
customers(id, name, email)
orders(id, customer_id, total_amount, status, created_at)
Quan hệ:
customers.id = orders.customer_id
Quy tắc:
- Chỉ tính orders có status = 'paid'.
- Chỉ tính đơn hàng trong 90 ngày gần đây.
- Không lấy email trong kết quả.
Kết quả cần trả về:
- customer_id
- name
- total_orders
- total_spent
Yêu cầu:
- Viết SQL tương thích MySQL.
- Giải thích ngắn gọn cách truy vấn hoạt động.
- Chỉ ra các index nên có nếu cần.
- Nếu có điểm có thể gây vấn đề hiệu năng, hãy cảnh báo.
Prompt này tốt hơn nhiều so với câu “viết SQL lấy khách hàng mua nhiều nhất” vì AI có đủ thông tin để xây dựng truy vấn dựa trên cấu trúc dữ liệu thực tế.
Để AI tạo SQL trước hay phân tích trước?
Với những truy vấn đơn giản, có thể yêu cầu AI tạo SQL trực tiếp. Nhưng với truy vấn có nhiều JOIN, subquery, CTE hoặc điều kiện nghiệp vụ phức tạp, nên yêu cầu AI phân tích logic trước rồi mới viết SQL.
Ví dụ, thay vì yêu cầu ngay:
Viết SQL cho báo cáo doanh thu theo tháng.
có thể yêu cầu:
Hãy phân tích bài toán trước khi viết SQL.
Tôi cần báo cáo doanh thu theo tháng.
Hãy xác định:
1. Những bảng cần sử dụng.
2. Quan hệ giữa các bảng.
3. Điều kiện để xác định một đơn hàng hợp lệ.
4. Cách tính doanh thu.
5. Cách nhóm dữ liệu theo tháng.
6. Những trường hợp có thể làm số liệu bị tính trùng.
Sau khi phân tích xong mới đưa ra câu SQL.
Cách này tạo ra một bước kiểm tra trung gian. Nếu AI hiểu sai bài toán ở phần phân tích, lập trình viên có thể phát hiện trước khi câu SQL được sử dụng.
Ví dụ thực tế: tạo truy vấn từ yêu cầu nghiệp vụ
Giả sử một website bán hàng có hai bảng:
products
- id
- name
- price
order_items
- id
- order_id
- product_id
- quantity
- price
Yêu cầu là tìm 10 sản phẩm có số lượng bán cao nhất.
Thay vì tự suy đoán, có thể đưa yêu cầu cho AI:
Hãy viết truy vấn MySQL để tìm 10 sản phẩm bán được nhiều đơn vị nhất.
Bảng products:
id, name, price
Bảng order_items:
id, order_id, product_id, quantity, price
Quan hệ:
products.id = order_items.product_id
Kết quả cần có:
- product_id
- product_name
- total_quantity
Sắp xếp total_quantity giảm dần.
Chỉ lấy 10 sản phẩm.
AI có thể tạo truy vấn theo hướng:
SELECT
p.id AS product_id,
p.name AS product_name,
SUM(oi.quantity) AS total_quantity
FROM products AS p
JOIN order_items AS oi
ON oi.product_id = p.id
GROUP BY p.id, p.name
ORDER BY total_quantity DESC
LIMIT 10;
Điều quan trọng không nằm ở việc AI viết được câu SQL này, mà ở khả năng kiểm tra xem nó có đúng với nghiệp vụ hay không.
Ví dụ, nếu order_items còn chứa sản phẩm thuộc các đơn đã hủy thì truy vấn trên có thể tính cả những sản phẩm không thực sự bán thành công. Khi đó cần bổ sung bảng orders và điều kiện trạng thái đơn hàng.
Đây chính là tư duy quan trọng khi sử dụng Vibe Coding: đừng đánh giá SQL chỉ bằng việc nó có chạy được hay không; hãy kiểm tra xem dữ liệu mà nó trả về có đúng ý nghĩa nghiệp vụ hay không.
Dùng Vibe Coding để kiểm tra câu SQL có đúng hay không
Sau khi AI tạo được một câu SQL, không nên lập tức đưa vào hệ thống. Bước tiếp theo là yêu cầu AI kiểm tra truy vấn theo từng góc độ: cú pháp, logic, dữ liệu trả về và hiệu năng.
Một prompt kiểm tra đơn giản có thể bắt đầu như sau:
Hãy review câu SQL dưới đây.
Kiểm tra riêng từng vấn đề:
- Cú pháp có hợp lệ không?
- JOIN có thể làm nhân bản dữ liệu không?
- Điều kiện WHERE có đúng với yêu cầu nghiệp vụ không?
- GROUP BY có chính xác không?
- Có trường hợp NULL làm sai kết quả không?
- Có nguy cơ truy vấn chậm khi dữ liệu lớn không?
- Có index nào nên bổ sung không?
Không tự thay đổi yêu cầu nghiệp vụ. Nếu phát hiện vấn đề, hãy giải thích nguyên nhân trước rồi mới đề xuất SQL sửa.
Cách yêu cầu này tốt hơn việc chỉ hỏi “SQL này có đúng không?” vì AI được buộc phải kiểm tra theo nhiều tiêu chí thay vì đưa ra một câu trả lời chung chung.
Kiểm tra lỗi nhân bản dữ liệu khi JOIN
Đây là một trong những lỗi nguy hiểm nhất khi sử dụng SQL có nhiều bảng. Truy vấn vẫn chạy bình thường nhưng kết quả tổng hợp có thể lớn hơn thực tế.
Ví dụ, một khách hàng có nhiều đơn hàng và mỗi đơn hàng lại có nhiều sản phẩm. Nếu JOIN nhiều bảng không đúng cấp độ dữ liệu, một dòng có thể bị nhân lên nhiều lần trước khi thực hiện SUM hoặc COUNT.
Khi gặp trường hợp này, có thể yêu cầu AI mô phỏng quan hệ:
Hãy kiểm tra truy vấn sau có làm nhân bản dòng trước khi SUM hay không.
Hãy mô tả số lượng dòng có thể phát sinh sau từng JOIN.
Nếu có nguy cơ tính tổng sai, hãy đưa ra cách sửa mà vẫn giữ nguyên yêu cầu nghiệp vụ.
Đây là cách sử dụng Vibe Coding ở mức sâu hơn: không chỉ nhờ AI viết SQL mà dùng AI để phản biện cách truy vấn đang xử lý dữ liệu.
Tối ưu SQL bằng cách yêu cầu AI phân tích Execution Plan
Một câu SQL chạy đúng chưa chắc đã chạy nhanh. Khi database có vài nghìn bản ghi, nhiều truy vấn có thể hoàn thành gần như tức thời. Nhưng khi dữ liệu tăng lên hàng triệu dòng, những điểm yếu trong truy vấn sẽ bắt đầu bộc lộ.
Thay vì yêu cầu AI đoán nguyên nhân truy vấn chậm, hãy cung cấp execution plan nếu hệ quản trị cơ sở dữ liệu hỗ trợ.
Ví dụ với MySQL có thể lấy kế hoạch thực thi bằng:
EXPLAIN
SELECT
p.id,
p.name,
SUM(oi.quantity) AS total_quantity
FROM products AS p
JOIN order_items AS oi
ON oi.product_id = p.id
GROUP BY p.id, p.name
ORDER BY total_quantity DESC
LIMIT 10;
Sau đó gửi kết quả EXPLAIN cho AI cùng với câu SQL và yêu cầu phân tích.
Đây là SQL và execution plan của truy vấn.
Hãy phân tích:
- Bảng nào đang được đọc nhiều dữ liệu nhất?
- Có full table scan không?
- Có index nào không được sử dụng?
- JOIN nào có khả năng gây tốn tài nguyên?
- ORDER BY hoặc GROUP BY có thể tạo chi phí lớn không?
- Có thể tối ưu mà không thay đổi kết quả không?
Ưu tiên giải pháp ít thay đổi cấu trúc hệ thống.
Thông tin execution plan giúp AI có dữ liệu thực tế để phân tích thay vì chỉ suy đoán từ câu SQL.
Dùng AI để tìm và đề xuất index phù hợp
Index là một trong những chủ đề Vibe Coding có thể hỗ trợ tốt, nhưng không nên để AI tự ý tạo hàng loạt index.
Ví dụ truy vấn thường xuyên lọc theo status và created_at:
SELECT id, customer_id, total_amount
FROM orders
WHERE status = 'paid'
AND created_at >= '2026-10-01';
Có thể yêu cầu AI phân tích:
Hãy phân tích nhu cầu index cho truy vấn này.
Bảng orders có:
- id: PRIMARY KEY
- customer_id
- total_amount
- status
- created_at
Truy vấn được chạy thường xuyên.
Hãy đề xuất index nếu cần và giải thích:
- Vì sao chọn các cột đó?
- Thứ tự cột trong composite index có ý nghĩa gì?
- Index có thể gây tác động gì đến INSERT và UPDATE?
- Có trường hợp nào index được đề xuất nhưng không nên tạo không?
Điểm cần nhớ là index không phải “càng nhiều càng tốt”. Mỗi index đều có chi phí lưu trữ và có thể làm các thao tác ghi dữ liệu tốn thêm tài nguyên.
Yêu cầu AI so sánh trước và sau khi thêm index
Thay vì hỏi AI “index này có tốt không?”, nên yêu cầu so sánh hai phương án.
Hãy so sánh hai phương án:
Phương án A:
Không thêm index mới.
Phương án B:
INDEX(status, created_at)
Phân tích tác động đối với:
- SELECT
- INSERT
- UPDATE
- kích thước index
- khả năng sử dụng index của truy vấn
Không kết luận chỉ dựa trên lý thuyết. Hãy chỉ ra những điểm cần kiểm tra bằng EXPLAIN hoặc benchmark thực tế.
Cách làm này giúp tránh tình trạng tối ưu theo cảm tính.
Nhờ Vibe Coding viết lại SQL nhưng không thay đổi kết quả
Đây là một tình huống rất hữu ích khi hệ thống đã có những truy vấn dài và khó bảo trì. Có thể đưa SQL hiện tại cho AI và yêu cầu viết lại với mục tiêu rõ ràng.
Hãy refactor câu SQL dưới đây.
Mục tiêu:
- Giữ nguyên kết quả.
- Không thay đổi quy tắc nghiệp vụ.
- Làm cấu trúc dễ đọc hơn.
- Giảm phần logic lặp lại nếu có.
- Chỉ thay đổi cách viết khi có cơ sở.
- Liệt kê từng thay đổi và giải thích vì sao thay đổi đó an toàn.
Nếu không thể chứng minh kết quả tương đương, hãy giữ nguyên phần đó.
Yêu cầu “giữ nguyên kết quả” rất quan trọng. Nếu chỉ yêu cầu AI “tối ưu SQL”, AI có thể thay đổi cách xử lý và vô tình làm thay đổi kết quả nghiệp vụ.
So sánh hai truy vấn thay vì tin ngay vào bản tối ưu
Khi AI đưa ra một truy vấn mới, có thể yêu cầu nó so sánh với truy vấn cũ:
So sánh SQL cũ và SQL mới.
Hãy kiểm tra:
1. Hai truy vấn có trả về cùng tập dữ liệu không?
2. Có khác nhau khi gặp NULL không?
3. Có khác nhau khi có dữ liệu trùng không?
4. Có khác nhau khi bảng không có bản ghi liên quan không?
5. Có khác nhau khi giá trị số bằng 0 không?
6. Có khác nhau về thứ tự kết quả khi không có ORDER BY không?
Không giả định hai truy vấn tương đương chỉ vì chúng cho cùng kết quả trên một vài dữ liệu mẫu.
Đây là bước đặc biệt cần thiết đối với các truy vấn có LEFT JOIN, GROUP BY, DISTINCT, EXISTS, subquery hoặc nhiều điều kiện phức tạp.
Vibe Coding với SQL JOIN, subquery và CTE
Khi SQL trở nên dài, AI có thể giúp chuyển một truy vấn khó đọc thành cấu trúc rõ ràng hơn. Một lựa chọn phổ biến là CTE.
Ví dụ, thay vì đặt toàn bộ logic vào một truy vấn duy nhất, có thể chia thành các bước có ý nghĩa:
WITH paid_orders AS (
SELECT
id,
customer_id,
total_amount
FROM orders
WHERE status = 'paid'
)
SELECT
customer_id,
COUNT(*) AS total_orders,
SUM(total_amount) AS total_spent
FROM paid_orders
GROUP BY customer_id;
Với Vibe Coding, có thể yêu cầu AI đánh giá xem việc dùng CTE có làm câu SQL dễ hiểu hơn hay không.
Hãy xem xét việc chuyển SQL hiện tại sang CTE.
Mục tiêu chính là tăng khả năng đọc và bảo trì, không phải thay đổi kết quả.
Nếu CTE không mang lại lợi ích rõ ràng hoặc có thể gây vấn đề hiệu năng trong hệ quản trị database đang sử dụng, hãy giữ cách viết hiện tại.
Điều này quan trọng vì CTE không phải lúc nào cũng là lựa chọn tối ưu. Cách database xử lý CTE phụ thuộc vào hệ quản trị và phiên bản cụ thể.
Những lỗi dễ gặp khi để AI viết SQL
Vibe Coding giúp tăng tốc nhưng cũng tạo ra một số rủi ro đặc thù. Người lập trình cần biết những lỗi nào phải kiểm tra trước khi đưa SQL vào production.
AI tự đoán tên bảng hoặc tên cột
Nếu schema không được cung cấp đầy đủ, AI có thể tạo ra các tên như users, orders hoặc created_at theo thói quen phổ biến. Câu SQL nhìn rất hợp lý nhưng lại không phản ánh database thực tế.
Giải pháp đơn giản là cung cấp schema chính xác và yêu cầu AI không tự tạo thêm cột nếu chưa được cung cấp.
Dùng SELECT * khi không cần thiết
AI thường sử dụng SELECT * trong các ví dụ đơn giản. Trong code thực tế, điều này có thể khiến truy vấn lấy nhiều dữ liệu hơn cần thiết, làm tăng lượng dữ liệu truyền và khiến code khó kiểm soát khi schema thay đổi.
Có thể yêu cầu:
Không sử dụng SELECT *.
Chỉ chọn những cột thực sự cần cho kết quả.
Nếu cần thêm cột để phục vụ JOIN hoặc điều kiện lọc, hãy giải thích lý do.
Lạm dụng DISTINCT để che lỗi JOIN
Đây là một trường hợp cần đặc biệt cảnh giác. Khi kết quả bị trùng, AI có thể đề xuất thêm DISTINCT. Cách này đôi khi làm mất các dòng trùng hợp lệ thay vì giải quyết nguyên nhân khiến dữ liệu bị nhân bản.
Nếu AI đề xuất DISTINCT, hãy hỏi tiếp:
Không mặc định dùng DISTINCT để loại bỏ dòng trùng.
Hãy xác định nguyên nhân tạo ra các dòng trùng trước.
Nếu vẫn cần DISTINCT, giải thích tại sao các dòng trùng đó không có ý nghĩa nghiệp vụ và vì sao dùng DISTINCT là an toàn.
Không xử lý đúng NULL
NULL không giống một chuỗi rỗng và cũng không giống số 0. Các biểu thức so sánh, phép tính và điều kiện với NULL có thể tạo ra kết quả khác với suy nghĩ thông thường.
Khi truy vấn có nhiều dữ liệu tùy chọn, nên yêu cầu AI kiểm tra riêng các trường hợp NULL:
Hãy kiểm tra toàn bộ truy vấn với các trường hợp:
- cột có NULL
- cột có chuỗi rỗng
- giá trị bằng 0
- không có bản ghi liên quan
Chỉ ra trường hợp nào có thể làm kết quả khác với yêu cầu nghiệp vụ.
Biến Vibe Coding thành quy trình kiểm soát SQL
Vibe Coding hiệu quả nhất khi được đưa vào một quy trình có kiểm soát thay vì sử dụng theo kiểu “hỏi AI rồi copy code”. Một quy trình thực tế có thể gồm các bước:
- Mô tả mục tiêu: nói rõ nghiệp vụ cần giải quyết.
- Cung cấp schema: đưa đúng bảng, cột và quan hệ liên quan.
- Nêu quy tắc: xác định trạng thái, điều kiện và các trường hợp đặc biệt.
- Yêu cầu AI phân tích: để phát hiện cách hiểu sai trước khi tạo SQL.
- Tạo truy vấn: yêu cầu SQL theo đúng hệ quản trị database đang dùng.
- Review: kiểm tra JOIN, GROUP BY, NULL và các điều kiện lọc.
- Kiểm tra execution plan: đặc biệt với truy vấn quan trọng hoặc dữ liệu lớn.
- Benchmark: đo thời gian thực tế trước và sau khi tối ưu.
- Kiểm thử dữ liệu: xác nhận kết quả đúng với những trường hợp quan trọng.
Quy trình này biến AI từ một công cụ “viết SQL hộ” thành một lớp hỗ trợ trong toàn bộ vòng đời của truy vấn. Người lập trình vẫn là người chịu trách nhiệm cuối cùng về tính chính xác và an toàn của câu lệnh.
Áp dụng Vibe Coding vào quy trình phát triển website
Trong một dự án website thực tế, SQL hiếm khi tồn tại độc lập. Câu lệnh thường nằm bên trong PHP, API hoặc một lớp truy cập database. Vì vậy, khi dùng Vibe Coding để tạo SQL, nên đặt truy vấn trong đúng bối cảnh mà nó sẽ được sử dụng.
Ví dụ, thay vì chỉ yêu cầu AI viết câu SQL lấy thông tin sản phẩm, có thể mô tả đầy đủ:
Website sử dụng PHP và MySQL.
Tôi cần lấy danh sách sản phẩm đang còn hàng để hiển thị ở trang danh mục.
Yêu cầu:
- Chỉ lấy sản phẩm có status = 'active'.
- Chỉ lấy sản phẩm có stock > 0.
- Sắp xếp sản phẩm mới nhất trước.
- Phân trang 20 sản phẩm mỗi trang.
- Không dùng SELECT *.
- Truy vấn phải sử dụng prepared statement khi nhận page từ người dùng.
Hãy đề xuất SQL và giải thích cách xử lý phần phân trang.
Cách mô tả này giúp AI hiểu rằng câu SQL không chỉ cần đúng về mặt dữ liệu mà còn phải phù hợp với cách ứng dụng sử dụng truy vấn.
Đưa yêu cầu phân trang vào ngay từ đầu
Phân trang là trường hợp dễ bị viết đơn giản quá mức. Nếu dữ liệu chỉ có vài trăm bản ghi, cách xử lý có thể không tạo ra vấn đề rõ ràng. Nhưng khi bảng có hàng triệu dòng, việc sử dụng OFFSET quá lớn có thể trở thành điểm nghẽn.
Có thể yêu cầu AI so sánh hai hướng:
Hãy so sánh phân trang bằng OFFSET/LIMIT với keyset pagination cho bảng products.
Bảng có hàng triệu bản ghi.
Trang danh sách được sắp xếp theo id tăng dần.
Phân tích:
- độ phức tạp khi chuyển đến trang rất sâu
- khả năng sử dụng index
- cách lấy trang tiếp theo
- ưu nhược điểm khi triển khai trong PHP
Nhờ vậy, Vibe Coding không chỉ giúp tạo câu SQL mà còn hỗ trợ lựa chọn cách truy vấn phù hợp với quy mô dữ liệu.
Kết hợp SQL với prepared statement khi lập trình
Một câu SQL được AI tạo ra có thể đúng về logic nhưng vẫn không an toàn nếu ghép trực tiếp dữ liệu người dùng vào chuỗi truy vấn.
Ví dụ không nên xây dựng truy vấn theo cách nối trực tiếp giá trị nhận từ request:
$keyword = $_GET['keyword'];
$sql = "SELECT id, name FROM products WHERE name LIKE '%$keyword%'";
Khi cần dữ liệu từ người dùng, nên yêu cầu AI viết truy vấn theo cơ chế tham số hóa.
$keyword = $_GET['keyword'] ?? '';
$sql = "SELECT id, name
FROM products
WHERE name LIKE :keyword";
$stmt = $pdo->prepare($sql);
$stmt->execute([
'keyword' => '%' . $keyword . '%'
]);
Trong quá trình Vibe Coding, có thể đặt quy tắc ngay trong prompt:
Tất cả dữ liệu đến từ người dùng phải được xử lý bằng prepared statement.
Không nối trực tiếp biến PHP vào SQL.
Nếu có phần SQL không thể bind bằng parameter, hãy giải thích cách xử lý an toàn thay vì tự nối chuỗi.
Đây là một trong những quy tắc nên đưa vào prompt mặc định của dự án thay vì nhắc lại ở từng truy vấn.
Không gửi dữ liệu nhạy cảm vào prompt
Để AI phân tích SQL, thường chỉ cần schema, cấu trúc bảng và một lượng dữ liệu mẫu đã được ẩn danh. Không nên đưa mật khẩu, token, khóa API hoặc thông tin cá nhân thực tế chỉ để minh họa cho một câu truy vấn.
Ví dụ, thay vì cung cấp dữ liệu thật:
email: nguyenvana@example.com
phone: 09xxxxxxxx
password: ********
có thể dùng dữ liệu giả:
email: user@example.com
phone: 0000000000
password: [REDACTED]
AI chủ yếu cần biết kiểu dữ liệu, tên cột và quan hệ giữa các trường. Trong phần lớn trường hợp, nó không cần dữ liệu sản xuất thực tế để viết hoặc review SQL.
Dùng dữ liệu mẫu để kiểm chứng truy vấn
Một trong những cách hiệu quả nhất để kiểm tra SQL do AI tạo là xây dựng một bộ dữ liệu nhỏ nhưng có chủ đích. Bộ dữ liệu này nên chứa cả trường hợp bình thường và những tình huống dễ làm truy vấn sai.
Ví dụ với hệ thống đơn hàng, dữ liệu kiểm thử nên có:
- Khách hàng có một đơn hàng.
- Khách hàng có nhiều đơn hàng.
- Khách hàng chưa từng mua hàng.
- Đơn hàng đã thanh toán.
- Đơn hàng bị hủy.
- Đơn hàng có nhiều sản phẩm.
- Sản phẩm không còn tồn tại hoặc đã bị ngừng bán.
- Dữ liệu có giá trị NULL.
- Hai bản ghi có cùng giá trị cần GROUP BY.
Sau đó có thể yêu cầu AI dự đoán kết quả trước khi chạy:
Dựa trên dữ liệu mẫu dưới đây, hãy dự đoán kết quả truy vấn.
Sau đó:
1. Giải thích cách tính từng dòng.
2. Chỉ ra dữ liệu nào được loại bỏ bởi WHERE.
3. Chỉ ra các dòng được tạo ra bởi JOIN.
4. Xác định trường hợp nào có thể gây sai kết quả.
Không sửa SQL ở bước này.
Cách làm này tạo ra một lớp kiểm tra logic trước khi truy vấn được chạy trên database thật.
Yêu cầu AI tạo nhiều phương án SQL để so sánh
Với truy vấn phức tạp, không nhất thiết phương án đầu tiên AI đưa ra là tốt nhất. Có thể yêu cầu nó xây dựng hai hoặc ba phương án với cách tiếp cận khác nhau rồi phân tích ưu nhược điểm.
Hãy giải quyết bài toán bằng 3 cách:
Phương án 1:
JOIN trực tiếp.
Phương án 2:
Sử dụng EXISTS hoặc subquery nếu phù hợp.
Phương án 3:
Sử dụng CTE nếu hệ quản trị database hỗ trợ.
Với mỗi phương án hãy phân tích:
- tính dễ đọc
- khả năng tối ưu
- khả năng sử dụng index
- rủi ro nhân bản dữ liệu
- khả năng bảo trì
Không chọn phương án chỉ vì câu SQL ngắn hơn.
Cách tiếp cận này đặc biệt hữu ích khi một truy vấn vừa phải chính xác vừa phải đáp ứng yêu cầu hiệu năng cao.
Khi nào không nên giao SQL hoàn toàn cho AI?
Vibe Coding phù hợp với việc tạo bản nháp và hỗ trợ phân tích, nhưng không nên biến thành cơ chế tự động đưa SQL vào production mà không có kiểm tra.
Cần đặc biệt thận trọng với những truy vấn:
- Thay đổi hoặc xóa số lượng lớn dữ liệu.
- Cập nhật dữ liệu tài chính.
- Tính doanh thu, lợi nhuận hoặc số liệu báo cáo quan trọng.
- Liên quan đến quyền truy cập người dùng.
- Sử dụng nhiều bảng với quan hệ phức tạp.
- Chạy trên bảng có hàng triệu hoặc hàng chục triệu dòng.
- Được thực thi thường xuyên trên hệ thống production.
Với các truy vấn này, AI có thể hỗ trợ phân tích nhưng quyết định cuối cùng nên dựa trên schema thực tế, execution plan, dữ liệu kiểm thử và benchmark.
Đặc biệt với UPDATE và DELETE, nên yêu cầu AI tạo câu SELECT tương ứng để kiểm tra tập dữ liệu trước khi thực hiện thay đổi.
Ví dụ, trước khi chạy:
DELETE FROM orders
WHERE status = 'cancelled'
AND created_at < '2025-01-01';
có thể yêu cầu AI chuyển điều kiện thành truy vấn kiểm tra:
SELECT id, customer_id, status, created_at
FROM orders
WHERE status = 'cancelled'
AND created_at < '2025-01-01';
Chỉ khi tập dữ liệu trả về đúng với dự kiến mới tiếp tục thực hiện thao tác thay đổi.
Thiết lập bộ quy tắc Vibe Coding cho SQL
Nếu thường xuyên dùng AI để lập trình, việc xây dựng một bộ quy tắc cố định sẽ giúp chất lượng đầu ra ổn định hơn. Thay vì mỗi lần phải nhắc lại những nguyên tắc cơ bản, có thể đưa chúng vào prompt nền của dự án.
Một bộ quy tắc thực tế có thể gồm:
- Không tự đoán bảng hoặc cột chưa được cung cấp.
- Không dùng SELECT * nếu không có lý do rõ ràng.
- Không dùng DISTINCT để che lỗi JOIN.
- Không thay đổi logic nghiệp vụ khi tối ưu.
- Kiểm tra NULL và dữ liệu trống.
- Ưu tiên prepared statement với dữ liệu từ người dùng.
- Không đưa thông tin nhạy cảm vào prompt.
- Với truy vấn chậm, yêu cầu kiểm tra execution plan.
- Không tạo index hàng loạt chỉ dựa trên suy đoán.
- Với UPDATE hoặc DELETE, phải kiểm tra tập dữ liệu bằng SELECT trước.
- Khi refactor SQL, phải giải thích vì sao kết quả vẫn tương đương.
Bộ quy tắc càng cụ thể thì AI càng dễ duy trì cùng một tiêu chuẩn khi hỗ trợ nhiều phần khác nhau của dự án.
Quy trình hoàn chỉnh để tạo và tối ưu SQL bằng Vibe Coding
Có thể rút gọn toàn bộ phương pháp thành một quy trình gồm tám bước:
- Xác định nghiệp vụ: hiểu chính xác người dùng hoặc hệ thống cần dữ liệu gì.
- Mô tả schema: cung cấp bảng, cột, kiểu quan hệ và những ràng buộc quan trọng.
- Nêu các trường hợp đặc biệt: NULL, trạng thái, dữ liệu trùng, bản ghi thiếu liên kết hoặc điều kiện thời gian.
- Yêu cầu AI phân tích: kiểm tra cách hiểu bài toán trước khi tạo SQL nếu truy vấn phức tạp.
- Tạo truy vấn: yêu cầu SQL phù hợp với đúng hệ quản trị database.
- Review: kiểm tra JOIN, GROUP BY, điều kiện lọc, NULL và khả năng SQL trả sai dữ liệu.
- Tối ưu: sử dụng EXPLAIN, index và benchmark thực tế thay vì chỉ dựa vào nhận xét của AI.
- Kiểm thử trước production: chạy trên dữ liệu mẫu hoặc môi trường staging trước khi triển khai.
Quy trình này giúp tốc độ của Vibe Coding không đánh đổi lấy độ tin cậy. AI có thể đảm nhận phần lớn công việc lặp lại như viết bản nháp, giải thích SQL, tìm vấn đề và đề xuất phương án, còn lập trình viên vẫn kiểm soát những quyết định ảnh hưởng đến dữ liệu và hệ thống.
Checklist trước khi đưa SQL do AI tạo vào production
Trước khi sử dụng một câu SQL được tạo hoặc tối ưu bằng Vibe Coding, có thể kiểm tra nhanh theo danh sách sau:
- Truy vấn có đúng hệ quản trị database đang sử dụng không?
- Tất cả bảng và cột có tồn tại thực tế không?
- Quan hệ JOIN có đúng không?
- Có nguy cơ nhân bản dòng không?
- WHERE có lọc đúng dữ liệu cần thiết không?
- GROUP BY và các hàm tổng hợp có phản ánh đúng nghiệp vụ không?
- NULL có thể làm thay đổi kết quả không?
- Có đang lấy nhiều cột hoặc nhiều dòng hơn cần thiết không?
- Có cần index không?
- Execution plan có điểm bất thường không?
- Truy vấn có được kiểm thử với dữ liệu thực tế hoặc dữ liệu mô phỏng đủ đa dạng không?
- Nếu là UPDATE hoặc DELETE, tập dữ liệu bị tác động đã được kiểm tra trước chưa?
- Dữ liệu từ người dùng có được xử lý bằng prepared statement không?
- Truy vấn có giữ nguyên kết quả sau khi tối ưu không?
Nếu một câu SQL vượt qua được những bước trên, khả năng đưa vào hệ thống an toàn và ổn định sẽ cao hơn nhiều so với việc chỉ kiểm tra xem câu lệnh có chạy thành công hay không.
Kết luận
Vibe Coding mở ra một cách tiếp cận rất thực tế để làm việc với SQL: lập trình viên mô tả bài toán bằng ngôn ngữ tự nhiên, AI hỗ trợ chuyển yêu cầu thành truy vấn, phân tích cấu trúc, tìm lỗi và đề xuất phương án tối ưu.
Tuy nhiên, giá trị lớn nhất không nằm ở việc AI viết SQL nhanh hơn con người. Điều quan trọng hơn là AI có thể trở thành một lớp hỗ trợ trong quá trình phân tích, review và tối ưu truy vấn, miễn là người lập trình cung cấp đủ ngữ cảnh và kiểm chứng kết quả.
Một câu SQL tốt không chỉ là câu lệnh chạy được. Nó phải trả về đúng dữ liệu, phản ánh đúng nghiệp vụ, xử lý được các trường hợp đặc biệt, có hiệu năng phù hợp và không tạo ra rủi ro bảo mật.
Vì vậy, cách sử dụng Vibe Coding hiệu quả nhất là: mô tả rõ, để AI đề xuất, kiểm tra logic, đo hiệu năng và chỉ triển khai khi kết quả đã được xác minh. Khi duy trì được quy trình này, AI có thể giúp rút ngắn đáng kể thời gian xử lý SQL mà vẫn giữ được quyền kiểm soát kỹ thuật trong tay lập trình viên.
- 0 Bình luận
Email, Điện thoại của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *
