Skrip Oracle SQL yang dihasilkan oleh ejen model bahasa besar (LLM) mungkin kelihatan sempurna di atas kertas, namun tetap boleh menyebabkan masalah besar semasa fasa produksi. Dalam satu kod legasi sebanyak 2.3 juta baris, ejen dipacu AI sering memasukkan pengenal pasti (identifiers) yang tidak wujud – sebagai contoh, menggunakan POLICY_STATUS dan bukannya lajur STATUS_CD yang sebenar, atau merujuk kepada jadual CUSTOMERS yang tidak wujud berbanding CUSTOMER.

Menjalankan skrip untuk mengesan kesilapan taip bukanlah pilihan bagi pernyataan UPDATE atau DELETE. Melaksanakannya pada set data menyerupai produksi akan menyebabkan penguncian (locks), menggunakan nombor urutan (sequence numbers), dan boleh mencetuskan kesan sampingan berantai. Pembangun memerlukan cara untuk mengesahkan nama dan sintaks tanpa menyentuh sebarang data. Jawapannya, yang secara mengejutkan adalah ringkas, ialah arahan EXPLAIN PLAN Oracle – yang digunakan semula sebagai langkah linting.

Bagaimana EXPLAIN PLAN berfungsi sebagai pengesah pantas

Apabila Oracle menerima sesuatu pernyataan, ia akan melakukan proses parsing terlebih dahulu. Parsing menyemak sama ada setiap jadual, lajur, dan keistimewaan (privilege) yang dirujuk wujud, kemudian membina pelan pelaksanaan dan menulis pelan tersebut ke dalam jadual sistem. Arahan tersebut tidak pernah menjalankan pernyataan itu: tiada baris yang diubah, tiada trigger yang dicetuskan, dan tiada penguncian yang diambil. Jika parser menemui objek yang tidak dikenali, ia akan mengeluarkan ralat dalam masa beberapa milisaat sahaja.

Tingkah laku tersebut menjadikan EXPLAIN PLAN sebagai semakan pra-penerbangan (pre-flight check) yang sempurna untuk SQL yang dihasilkan oleh AI. Jadual atau lajur yang hilang akan dilaporkan serta-merta, membolehkan gelung penjanaan (generation loop) membetulkan kesilapan tersebut sebelum manusia melihat skrip itu.

Aliran kerja yang saya integrasikan ke dalam saluran paip (pipeline) CI saya

  1. Bahagikan skrip yang masuk kepada pernyataan individu.
  2. Jalankan EXPLAIN PLAN FOR <statement> terhadap skema pembangunan.
  3. Kumpul sebarang ralat parsing yang dikembalikan oleh Oracle.
  4. Berikan ralat tersebut semula kepada LLM untuk cubaan semula.

Dalam praktiknya, satu cubaan semula sudah memadai untuk menyelesaikan sebahagian besar ralat penamaan. AI akan mempelajari skema yang betul dan melaraskan outputnya secara automatik. Saya juga mengunci ejen tersebut dalam mod baca-sahaja: ia boleh mengeluarkan arahan SELECT dan panggilan EXPLAIN PLAN, tetapi DDL, DML, dan COMMIT disekat. Sandbox tersebut menjamin pangkalan data kekal tidak disentuh sementara AI meneroka strukturnya.

Selain semakan nama, pelan yang dihasilkan mendedahkan tanda amaran prestasi yang jelas. Jika sesuatu pernyataan akan mencetuskan imbasan jadual penuh (full-table scan) pada jadual yang besar, pelan tersebut akan menunjukkannya sebelum sebarang baris disentuh, memberikan peluang kepada pembangun untuk mencadangkan indeks atau menulis semula predikat.

Had pendekatan ini

  • Ketepatan logik tidak disahkan. Satu pernyataan yang merujuk kepada lajur yang betul tetapi menggunakan penapis (filter) yang salah tetap akan melepasi lint.
  • Blok PL/SQL di luar skop. Parser hanya mengendalikan pernyataan SQL individu; kod prosedur memerlukan laluan pengesahan yang berasingan.
  • Pengesahan tahap data tidak tersedia. Lint tersebut tidak dapat memberitahu anda sama ada nilai literal mematuhi domain sesuatu lajur atau sama ada rujukan kunci asing (foreign-key) benar-benar wujud.
  • Hanya skema pembangunan. Ralat yang hanya muncul dalam produksi – sebagai contoh, jadual yang wujud dalam pembangunan tetapi telah ditukar namanya dalam produksi – akan kekal tidak kelihatan sehingga kemudian.

Jurang ini tidak mengurangkan kegunaan kaedah tersebut; ia hanya menentukan sempadannya. Bagi kebanyakan skrip DML yang dihasilkan oleh LLM, mod kegagalan yang paling biasa ialah kesilapan taip atau nama objek yang salah, dan itulah sebenarnya yang dikesan oleh EXPLAIN PLAN.

Kebolehpindahan ke enjin pangkalan data lain

Prinsip yang sama terpakai melangkaui Oracle. Pernyataan PREPARE atau EXPLAIN dalam PostgreSQL boleh melakukan parsing pada pertanyaan tanpa pelaksanaan. SQL Server menawarkan SET PARSEONLY ON, yang memaksa enjin untuk mengesahkan sintaks dan nama objek sambil melangkau pemprosesan sebenar. Mana-mana RDBMS yang memisahkan parsing daripada pelaksanaan boleh menjadi gerbang linting yang ringan.

Kesimpulan

Menjalankan EXPLAIN PLAN (atau setaranya) pada setiap pernyataan SQL yang dihasilkan oleh AI menukarkan parser pangkalan data menjadi gerbang linting yang murah dan tanpa risiko. Ia mengesan ralat penamaan dan sintaks yang paling kerap sebelum sebarang data dialihkan, memastikan sistem legasi kekal stabil sambil membolehkan pembangun menikmati peningkatan produktiviti daripada pengekodan berbantuan LLM.