Temu duga kejuruteraan data: Bagaimanakah anda menggunakan lajur tidak kelihatan (invisible columns) MySQL untuk evolusi skema yang selamat?

Gesaan dan konteks

Klien lama bergantung pada SELECT * dan penyahkodan hasil berasaskan kedudukan (posisional), manakala perkhidmatan baharu memerlukan medan tambahan. Terangkan bagaimana lajur INVISIBLE MySQL 8.4 membolehkan klien lama dan baharu wujud bersama, termasuk rujukan eksplisit, nilai lalai penulisan, indeks, sandaran dan sempadan rollback.

Perkara yang dinilai oleh penemu duga

• Sama ada anda memahami bahawa sifat tidak kelihatan mengubah pengembangan lajur tersirat, bukannya storan atau penyertaan dalam kekangan (constraints).
• Sama ada anda membezakan antara SELECT *, senarai eksplisit, senarai INSERT dan CREATE TABLE ... SELECT.
• Sama ada anda mempertimbangkan kunci utama dan unik, kunci asing, kekangan semakan (check constraints), pengelogan binari (binary logging) dan pemulihan sandaran.
• Sama ada anda boleh merancang pelancaran berperingkat, kebolehcerapan (observability) dan peralihan akhir kepada pertanyaan VISIBLE.

Soalan penjelasan untuk ditanya

Sahkan versi MySQL, enjin storan, topologi replikasi, alat sandaran dan sama ada klien lama benar-benar menyahkod mengikut kedudukan. Tanya sama ada medan baharu memerlukan nilai lalai, mengambil bahagian dalam kekangan unik, digunakan oleh laporan atau CDC, dan mesti kekal bersama datanya selepas rollback.

Jawapan 30 saat

Lajur tidak kelihatan masih merupakan sebahagian daripada jadual, tetapi SELECT * dan tbl.* mengetepikan lajur tersebut; rujukan eksplisit boleh membaca dan menulis kepadanya. Tambah medan sebagai INVISIBLE supaya struktur hasil klien lama kekal stabil, manakala klien baharu menggunakan senarai eksplisit untuk bacaan dan isian semula (backfills). Uji nilai lalai, indeks unik, kunci asing, CDC, pemulihan sandaran dan keterlihatan CREATE TABLE ... SELECT. Selepas setiap pengguna berhijrah, tukar keterlihatan kepada VISIBLE. Ia adalah alat keserasian, bukan mekanisme kebenaran atau pengasingan data.

Analisis mendalam langkah demi langkah

1. Sahkan semantik lajur tidak kelihatan

Dalam MySQL 8.4, lajur tidak kelihatan tidak terdapat dalam hasil SELECT *, tbl.* dan TABLE melainkan dinamakan secara eksplisit. Ia tidak menyembunyikan storan, indeks atau kekangan, dan ia bukan kawalan capaian peringkat lajur.

2. Reka DDL yang serasi

Gunakan ALTER TABLE ... ADD COLUMN ... INVISIBLE dan pilih nilai lalai yang selamat atau tingkah laku NULL untuk penulisan lama. Kekalkan sekurang-kurangnya satu lajur yang kelihatan. Klien baharu harus bermula dengan senarai eksplisit dan bukannya meneruskan kontrak *.

3. Sahkan bacaan, penulisan dan kekangan

Klien lama sepatutnya menerima set lajur asal. Klien baharu membaca dan menulis medan tersebut secara eksplisit; lajur tidak kelihatan yang ditinggalkan akan menerima tingkah laku lalai tersirat MySQL. Kekangan kunci utama, unik, kunci asing dan semakan masih terpakai, jadi uji pertindihan, kaskad dan transaksi yang gagal.

4. Ambil kira replikasi dan talian paip data

Lajur tidak kelihatan dianggap seperti lajur kelihatan dalam peristiwa baris (row events); penyertaannya bergantung pada tetapan seperti binlog_row_image. Uji CDC, ETL, pemetaan ORM dan semakan kualiti data dengan senarai lajur sebenar dan bukannya membuat kesimpulan tentang replikasi daripada SELECT *.

5. Tulis skrip migrasi terkecil

ALTER TABLE orders
  ADD COLUMN risk_score DECIMAL(5, 2) NULL INVISIBLE;

SELECT order_id, status, risk_score
FROM orders
WHERE order_id = ?;

ALTER TABLE orders
  MODIFY COLUMN risk_score DECIMAL(5, 2) NULL VISIBLE;

Jalankan DDL terlebih dahulu, gunakan bacaan eksplisit dan isian semula, perhatikan ralat klien lama dan kelambatan CDC, dan hanya selepas itu tukar keterlihatan. Perancangan pengeluaran juga mesti menilai kunci (locks), sokongan online-DDL dan tetingkap rollback.

6. Periksa sandaran, penciptaan jadual dan pemulihan

mysqldump dan SHOW CREATE TABLE mengekalkan metadata sifat tidak kelihatan. Memulihkan ke pelayan lebih lama yang tidak menyokong ciri ini boleh menjadikan lajur itu kelihatan kerana komen versi diabaikan. Lajur tidak kelihatan yang eksplisit dalam CREATE TABLE ... SELECT mungkin menjadi kelihatan pada sasaran melainkan definisinya mengulangi INVISIBLE.

Contoh jawapan berkualiti tinggi

Saya akan menganggap lajur tidak kelihatan sebagai alat keserasian, bukan sempadan keselamatan. Mula-mula, sahkan bahawa klien lama benar-benar bergantung pada SELECT *, kemudian tambah lajur INVISIBLE dengan semantik boleh-batal (nullable) atau nilai lalai yang selamat melalui laluan DDL dalam talian. Klien lama mengekalkan struktur hasil asalnya; klien baharu mesti menggunakan senarai eksplisit untuk bacaan, isian semula dan penulisan. Ujian merangkumi nilai lalai, kemas kini eksplisit, konflik kunci utama dan unik, kunci asing dan semakan, pemetaan ORM, tingkah laku CDC di bawah binlog_row_image, pemulihan sandaran dan keterlihatan CREATE TABLE ... SELECT. Semasa migrasi, pantau kadar ralat, kelambatan replikasi dan integriti data. Selepas setiap pengguna menggunakan kontrak eksplisit yang stabil, tukar medan kepada VISIBLE. Rollback boleh memulihkan versi aplikasi sambil mengekalkan lajur dan data; pemulihan merentasi versi memerlukan semakan sokongan dan metadata dump. Untuk jangka panjang, buang SELECT * supaya kontrak hasil menjadi eksplisit.

Kesilapan lazim

• Menganggap lajur tidak kelihatan tidak terlibat dalam kunci, semakan, kunci asing atau pengelogan binari.
• Hanya menguji SELECT * dan melangkau bacaan eksplisit, penulisan dan pemetaan ORM.
• Menganggap sifat tidak kelihatan sebagai kebenaran lajur, privasi atau pengasingan data.
• Mengabaikan CREATE TABLE ... SELECT, pemulihan dump dan tingkah laku pelayan yang lebih lama.
• Terus menggunakan SELECT * dalam klien baharu dan mencipta semula masalah keserasian kemudian hari.

Soalan susulan dan jawapan

Adakah lajur tidak kelihatan menyelesaikan setiap masalah keserasian SELECT *?

Tidak. Ia menstabilkan set yang dikembalikan, tetapi penyahkodan berasaskan kedudukan, pantulan ORM, laporan dan CDC masih memerlukan pengesahan individu. Penyelesaian jangka panjang ialah menggunakan senarai lajur eksplisit.

Apakah yang berlaku semasa operasi insert apabila lajur tidak kelihatan ditinggalkan?

Ia menerima tingkah laku lalai tersirat MySQL. Untuk menulis nilai tertentu, namakan lajur secara eksplisit dan uji NOT NULL, kekangan unik dan kekangan semakan.

Bilakah anda patut menukarnya kembali kepada VISIBLE?

Selepas operasi baca, tulis, CDC, sandaran dan laporan semuanya menggunakan kontrak eksplisit yang stabil, serta lulus pemantauan dan latihan rollback. Kemudian tukar keterlihatan dalam pelancaran berperingkat.