Wawancara data engineering: Bagaimana cara menggunakan invisible columns di MySQL untuk evolusi skema yang aman?

Petunjuk dan konteks

Sebuah klien lama bergantung pada SELECT * dan decoding hasil berdasarkan posisi (posisional), sementara layanan baru memerlukan field tambahan. Jelaskan bagaimana kolom INVISIBLE pada MySQL 8.4 memungkinkan klien lama dan baru hidup berdampingan, termasuk referensi eksplisit, nilai default penulisan, indeks, backup, dan batasan rollback.

Hal yang dievaluasi oleh pewawancara

• Apakah Anda memahami bahwa sifat invisible mengubah ekspansi kolom implisit, bukan penyimpanan atau partisipasi dalam constraint.
• Apakah Anda membedakan antara SELECT *, daftar eksplisit, daftar INSERT, dan CREATE TABLE ... SELECT.
• Apakah Anda mempertimbangkan primary dan unique key, foreign key, check constraint, binary logging, dan restore backup.
• Apakah Anda dapat merencanakan peluncuran bertahap (staged rollout), observabilitas, dan langkah akhir menuju query VISIBLE.

Pertanyaan klarifikasi yang perlu diajukan

Konfirmasikan versi MySQL, storage engine, topologi replikasi, alat backup, dan apakah klien lama benar-benar melakukan decoding berdasarkan posisi. Tanyakan apakah field baru memerlukan nilai default, berpartisipasi dalam unique constraint, dikonsumsi oleh laporan atau CDC, dan harus tetap bertahan setelah rollback beserta datanya.

Jawaban 30 detik

Kolom invisible tetap menjadi bagian dari tabel, tetapi SELECT * dan tbl.* mengabaikannya; referensi eksplisit dapat membaca dan menulis ke kolom tersebut. Tambahkan field sebagai INVISIBLE agar bentuk hasil untuk klien lama tetap stabil, sementara klien baru menggunakan daftar eksplisit untuk membaca dan backfill. Uji nilai default, unique index, foreign key, CDC, restore backup, dan visibilitas CREATE TABLE ... SELECT. Setelah semua konsumen bermigrasi, ubah visibilitas menjadi VISIBLE. Ini adalah alat bantu kompatibilitas, bukan mekanisme otorisasi atau isolasi data.

Pembahasan mendalam langkah demi langkah

1. Konfirmasikan semantik invisible column

Pada MySQL 8.4, kolom invisible tidak muncul dalam hasil SELECT *, tbl.*, dan TABLE kecuali disebutkan secara eksplisit. Fitur ini tidak menyembunyikan penyimpanan, indeks, atau constraint, dan bukan merupakan kontrol akses tingkat kolom.

2. Rancang DDL yang kompatibel

Gunakan ALTER TABLE ... ADD COLUMN ... INVISIBLE dan pilih nilai default yang aman atau perilaku NULL untuk operasi penulisan lama. Pertahankan setidaknya satu kolom yang terlihat (visible). Klien baru harus mulai menggunakan daftar eksplisit alih-alih melanjutkan kontrak *.

3. Validasi pembacaan, penulisan, dan constraint

Klien lama harus menerima set kolom asli. Klien baru membaca dan menulis field tersebut secara eksplisit; kolom invisible yang diabaikan akan menerima perilaku default implisit MySQL. Primary key, unique constraint, foreign key, dan check constraint tetap berlaku, jadi ujilah duplikasi data, cascade, dan transaksi yang gagal.

4. Perhitungkan replikasi dan pipeline data

Kolom invisible diperlakukan sama seperti kolom visible dalam row events; penyertaannya bergantung pada pengaturan seperti binlog_row_image. Uji CDC, ETL, pemetaan ORM, dan pemeriksaan kualitas data dengan daftar kolom sebenarnya alih-alih menyimpulkan replikasi dari SELECT *.

5. Tulis skrip migrasi paling ringkas

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, terapkan pembacaan eksplisit dan backfill, amati error pada klien lama dan lag CDC, lalu baru ubah visibilitasnya. Perencanaan produksi juga harus menilai penguncian (locks), dukungan online-DDL, dan jendela waktu rollback.

6. Periksa backup, pembuatan tabel, dan restore

mysqldump dan SHOW CREATE TABLE mempertahankan metadata invisibilitas. Merestore ke server lama yang tidak mendukung fitur ini dapat membuat kolom menjadi visible karena komentar versi diabaikan. Kolom invisible eksplisit pada CREATE TABLE ... SELECT dapat menjadi visible di target kecuali definisinya mengulang klausa INVISIBLE.

Contoh jawaban berkualitas tinggi

Saya akan memperlakukan kolom invisible sebagai alat kompatibilitas, bukan batasan keamanan. Pertama, verifikasi apakah klien lama benar-benar bergantung pada SELECT *, kemudian tambahkan kolom INVISIBLE dengan semantik nullable atau default yang aman melalui jalur online DDL. Klien lama tetap mempertahankan format hasil aslinya; klien baru harus menggunakan daftar eksplisit untuk pembacaan, backfill, dan penulisan. Pengujian mencakup nilai default, pembaruan eksplisit, konflik primary dan unique key, foreign key dan check constraint, pemetaan ORM, perilaku CDC di bawah binlog_row_image, restore backup, dan visibilitas CREATE TABLE ... SELECT. Selama migrasi, pantau tingkat error, lag replikasi, dan integritas data. Setelah setiap konsumen menggunakan kontrak eksplisit yang stabil, ubah field menjadi VISIBLE. Rollback dapat memulihkan versi aplikasi sambil mempertahankan kolom dan data; restore lintas versi memerlukan pemeriksaan dukungan dan metadata dump. Untuk jangka panjang, hilangkan SELECT * agar kontrak hasil menjadi eksplisit.

Kesalahan umum

• Mengasumsikan kolom invisible tidak berpartisipasi dalam key, check constraint, foreign key, atau binary logging.
• Hanya menguji SELECT * dan melewatkan pengujian pembacaan eksplisit, penulisan, serta pemetaan ORM.
• Memperlakukan invisibilitas sebagai izin akses kolom, privasi, atau isolasi data.
• Mengabaikan CREATE TABLE ... SELECT, restore dump, dan perilaku server lama.
• Terus menggunakan SELECT * pada klien baru dan menciptakan kembali masalah kompatibilitas di masa mendatang.

Pertanyaan lanjutan dan tanggapan

Apakah kolom invisible menyelesaikan setiap masalah kompatibilitas SELECT *?

Tidak. Ini menstabilkan set hasil yang dikembalikan, tetapi decoding posisional, refleksi ORM, laporan, dan CDC tetap memerlukan validasi masing-masing. Solusi jangka panjang adalah daftar kolom eksplisit.

Apa yang terjadi pada operasi insert ketika kolom invisible diabaikan?

Kolom tersebut menerima perilaku default implisit MySQL. Untuk menulis nilai tertentu, sebutkan nama kolom secara eksplisit dan uji NOT NULL, unique constraint, serta check constraint.

Kapan Anda harus mengubahnya kembali menjadi VISIBLE?

Setelah operasi baca, tulis, CDC, backup, dan laporan semuanya menggunakan kontrak eksplisit yang stabil, serta lulus pengujian pemantauan dan simulasi rollback. Kemudian ubah visibilitas dalam peluncuran bertahap.