Các kịch bản Oracle SQL được tạo ra bởi các tác nhân mô hình ngôn ngữ lớn (LLM) có thể trông hoàn hảo trên lý thuyết nhưng vẫn có thể gây ra thảm họa khi chạy thực tế (production). Trong một codebase cũ lên tới 2,3 triệu dòng, một tác nhân AI thường xuyên đưa vào các định danh không tồn tại – ví dụ, sử dụng cột POLICY_STATUS thay vì cột STATUS_CD thực tế, hoặc tham chiếu đến bảng CUSTOMERS không tồn tại thay vì CUSTOMER.
Việc chạy thử script để bắt lỗi đánh máy không phải là một lựa chọn khả thi đối với các câu lệnh UPDATE hoặc DELETE. Thực thi chúng trên một tập dữ liệu mô phỏng production sẽ tạo ra các khóa (locks), tiêu tốn các số sequence và có thể gây ra các tác dụng phụ dây chuyền. Các nhà phát triển cần một cách để xác thực tên và cú pháp mà không chạm vào bất kỳ dữ liệu nào. Câu trả lời, một cách đáng ngạc nhiên là đơn giản, chính là lệnh EXPLAIN PLAN của Oracle – được tái sử dụng như một bước linting.
Cách EXPLAIN PLAN hoạt động như một bộ xác thực nhanh
Khi Oracle nhận được một câu lệnh, trước tiên nó sẽ phân tích cú pháp (parse). Quá trình phân tích cú pháp sẽ kiểm tra xem mọi bảng, cột và quyền hạn được tham chiếu có tồn tại hay không, sau đó xây dựng một kế hoạch thực thi (execution plan) và ghi kế hoạch đó vào một bảng hệ thống. Lệnh này không bao giờ thực thi câu lệnh: không có hàng nào bị sửa đổi, không có trigger nào được kích hoạt, không có khóa nào bị chiếm giữ. Nếu bộ phân tích cú pháp gặp một đối tượng không xác định, nó sẽ báo lỗi chỉ trong vài mili giây.
Hành vi đó khiến EXPLAIN PLAN trở thành một bước kiểm tra tiền vận hành (pre-flight check) hoàn hảo cho SQL do AI tạo ra. Một bảng hoặc cột bị thiếu sẽ được báo cáo ngay lập tức, cho phép vòng lặp tạo mã sửa lỗi trước khi con người kịp nhìn thấy script.
Quy trình làm việc tôi đã tích hợp vào pipeline CI của mình
- Chia nhỏ script đầu vào thành các câu lệnh riêng lẻ.
- Chạy
EXPLAIN PLAN FOR <statement>trên một schema phát triển (development schema). - Thu thập bất kỳ lỗi phân tích cú pháp nào mà Oracle trả về.
- Gửi các lỗi đó ngược lại cho LLM để thử lại.
Trong thực tế, chỉ cần một lần thử lại là có thể giải quyết phần lớn các lỗi đặt tên. AI sẽ học được schema chính xác và tự động điều chỉnh đầu ra của nó. Tôi cũng khóa tác nhân ở chế độ chỉ đọc (read-only): nó có thể thực hiện các lệnh SELECT và gọi EXPLAIN PLAN, nhưng các lệnh DDL, DML và COMMIT đều bị chặn. Môi trường sandbox đó đảm bảo cơ sở dữ liệu không bị tác động trong khi AI thăm dò cấu trúc của nó.
Ngoài việc kiểm tra tên, kế hoạch được tạo ra còn tiết lộ các dấu hiệu cảnh báo hiệu suất rõ ràng. Nếu một câu lệnh sẽ kích hoạt việc quét toàn bộ bảng (full-table scan) trên một bảng khổng lồ, kế hoạch sẽ hiển thị điều đó trước khi bất kỳ hàng nào bị chạm tới, giúp các nhà phát triển có cơ hội đề xuất thêm index hoặc viết lại điều kiện lọc (predicate).
Hạn chế của phương pháp này
- Không xác thực được tính đúng đắn về logic. Một câu lệnh tham chiếu đúng các cột nhưng áp dụng sai bộ lọc vẫn sẽ vượt qua bước linting.
- Các khối PL/SQL nằm ngoài phạm vi. Bộ phân tích cú pháp chỉ xử lý các câu lệnh SQL riêng lẻ; mã thủ tục (procedural code) cần một lộ trình xác thực riêng.
- Thiếu xác thực ở cấp độ dữ liệu. Bước linting không thể cho bạn biết liệu một giá trị cụ thể có phù hợp với miền giá trị (domain) của một cột hay liệu một tham chiếu khóa ngoại có thực sự tồn tại hay không.
- Chỉ áp dụng cho schema dev. Các lỗi chỉ xuất hiện trong môi trường production – ví dụ, một bảng tồn tại trong dev nhưng đã được đổi tên trong prod – sẽ vẫn không được phát hiện cho đến giai đoạn sau.
Những lỗ hổng này không làm giảm đi tính hữu dụng của phương pháp; chúng chỉ đơn giản là xác định phạm vi của nó. Đối với hầu hết các script DML do LLM tạo ra, lỗi phổ biến nhất là lỗi đánh máy hoặc sai tên đối tượng, và đó chính xác là những gì EXPLAIN PLAN bắt được.
Khả năng tương thích với các công cụ cơ sở dữ liệu khác
Nguyên tắc tương tự cũng áp dụng cho các hệ quản trị cơ sở dữ liệu khác ngoài Oracle. Câu lệnh PREPARE hoặc EXPLAIN của PostgreSQL có thể phân tích một truy vấn mà không cần thực thi. SQL Server cung cấp SET PARSEONLY ON, buộc engine phải xác thực cú pháp và tên đối tượng trong khi bỏ qua quá trình xử lý thực tế. Bất kỳ RDBMS nào tách biệt việc phân tích cú pháp khỏi việc thực thi đều có thể trở thành một cổng kiểm tra (linting gate) nhẹ nhàng.
Bài học rút ra
Việc chạy EXPLAIN PLAN (hoặc lệnh tương đương) trên mọi câu lệnh SQL do AI tạo ra sẽ biến bộ phân tích cú pháp cơ sở dữ liệu thành một cổng linting chi phí thấp và không rủi ro. Nó bắt được các lỗi đặt tên và cú pháp thường gặp nhất trước khi bất kỳ dữ liệu nào bị dịch chuyển, giúp giữ cho các hệ thống cũ luôn ổn định trong khi vẫn cho phép các nhà phát triển tận dụng sự gia tăng năng suất từ việc lập trình với sự hỗ trợ của LLM.