Banyak developer memakai MySQL setiap hari hanya lewat ORM tanpa tahu apa yang terjadi di dalamnya. Memahami cara kerjanya membuat kamu lebih mudah menganalisis masalah performa, menjaga konsistensi data, dan mengamankan server. Artikel ini membahas MySQL dari sisi cara kerja dan administrasi; untuk dasar perintah SQL baca Mengenal Database MySQL untuk Pemula.
Arsitektur singkat
MySQL menggunakan model client-server. Aplikasi (client) mengirim query lewat jaringan (port 3306 secara default) ke proses server mysqld. Di dalam server, sebuah query melewati beberapa lapisan:
- Connection layer: autentikasi, manajemen koneksi.
- Parser dan optimizer: memeriksa sintaks lalu memilih rencana eksekusi paling murah (inilah yang ditampilkan
EXPLAIN). - Storage engine: lapisan yang benar-benar menyimpan dan mengambil data.
Pemisahan ini membuat MySQL mendukung beberapa mesin penyimpanan.
Mesin penyimpanan: InnoDB vs MyISAM
| Aspek | InnoDB (bawaan) | MyISAM (lama) |
|---|---|---|
| Transaksi | Ya (ACID) | Tidak |
| Foreign key | Ya | Tidak |
| Penguncian | Per baris | Per tabel |
| Pemulihan saat crash | Ya (redo log) | Lemah |
| Cocok untuk | Hampir semua aplikasi modern | Hampir tidak ada lagi |
Gunakan InnoDB. Periksa dengan SHOW TABLE STATUS bahwa tabelmu tidak memakai MyISAM.
Transaksi dan ACID
Transaksi mengelompokkan beberapa perintah menjadi satu kesatuan: semua berhasil atau semuanya dibatalkan. Contoh klasik: transfer saldo.
START TRANSACTION;
UPDATE rekening SET saldo = saldo - 100000 WHERE id = 1;
UPDATE rekening SET saldo = saldo + 100000 WHERE id = 2;
COMMIT; -- atau ROLLBACK; jika terjadi masalah
Jaminan ACID:
- Atomicity: semua langkah berhasil atau tidak sama sekali.
- Consistency: data selalu berpindah dari satu kondisi valid ke kondisi valid lain.
- Isolation: transaksi yang berjalan bersamaan tidak saling mengganggu.
- Durability: data yang sudah di-COMMIT bertahan walau server mati.
Di Laravel: DB::transaction(function () { ... });.
Level isolasi
Isolasi mengatur seberapa jauh transaksi bisa "melihat" perubahan transaksi lain.
| Level | Masalah yang mungkin terjadi |
|---|---|
READ UNCOMMITTED | Dirty read |
READ COMMITTED | Non-repeatable read |
REPEATABLE READ (bawaan InnoDB) | Phantom read (diredam oleh next-key lock InnoDB) |
SERIALIZABLE | Paling aman, paling lambat |
InnoDB memakai MVCC (multi-version concurrency control): pembacaan tidak memblokir penulisan, karena pembaca melihat "foto" data pada saat transaksi dimulai. Gunakan SELECT ... FOR UPDATE bila perlu mengunci baris sebelum mengubahnya (misalnya mengurangi stok).
Deadlock
Dua transaksi saling menunggu kunci yang dipegang yang lain; MySQL membatalkan salah satunya dengan error Deadlock found. Cara menguranginya:
- Selalu mengakses tabel/baris dalam urutan yang sama.
- Buat transaksi sesingkat mungkin.
- Siapkan logika coba ulang di aplikasi.
Karakter set dan collation
- Gunakan
utf8mb4agar mendukung seluruh karakter Unicode, termasuk emoji. - Collation menentukan aturan pengurutan dan perbandingan (misalnya
utf8mb4_unicode_citidak membedakan huruf besar/kecil). - Samakan charset di database, tabel, dan koneksi untuk menghindari teks rusak dan perbandingan lambat.
Pengguna dan hak akses
Prinsip least privilege: aplikasi hanya diberi hak yang dibutuhkan.
CREATE USER 'app_toko'@'10.0.0.%' IDENTIFIED BY 'KataSandiKuat!2025';
GRANT SELECT, INSERT, UPDATE, DELETE ON toko.* TO 'app_toko'@'10.0.0.%';
FLUSH PRIVILEGES;
- Jangan memakai akun
rootdi aplikasi. - Batasi asal koneksi (
@'10.0.0.%', bukan@'%'). - Akun migrasi bisa punya hak tambahan (
CREATE,ALTER) yang tidak dimiliki akun aplikasi harian. - Jangan membuka port 3306 ke internet; batasi dengan firewall atau jaringan privat.
Backup dan pemulihan
Backup yang belum pernah diuji bukan backup.
| Metode | Keterangan |
|---|---|
mysqldump | Logis, portabel, cocok untuk database kecil-menengah: mysqldump --single-transaction toko > toko.sql |
| Percona XtraBackup / MySQL Enterprise Backup | Fisik, cepat untuk database besar, tanpa mengunci |
| Binary log (binlog) | Memungkinkan point-in-time recovery |
| Snapshot disk/ cloud | Cepat, pastikan konsisten |
Aturan 3-2-1: 3 salinan, 2 jenis media, 1 salinan di lokasi lain. Jadwalkan otomatis dan uji pemulihan secara berkala.
Pemulihan: mysql toko < toko.sql.
Replikasi dan skalabilitas
- Replikasi source-replica: replica menyalin perubahan dari source lewat binlog. Dipakai untuk membagi beban baca, cadangan hidup, dan pelaporan tanpa mengganggu produksi.
- Aplikasi dapat mengirim baca ke replica dan tulis ke source (Laravel mendukung ini lewat konfigurasi
read/write). Waspadai replication lag: data baru mungkin belum terlihat di replica. - Opsi lanjut: cluster (Group Replication, InnoDB Cluster), sharding, dan layanan terkelola (RDS, Cloud SQL).
Konfigurasi yang paling berdampak
| Parameter | Fungsi |
|---|---|
innodb_buffer_pool_size | Memori cache data dan index; pada server khusus database sering diatur 60-70% RAM |
max_connections | Batas koneksi bersamaan |
slow_query_log, long_query_time | Merekam query lambat |
innodb_flush_log_at_trx_commit | Kompromi antara durabilitas dan kecepatan |
sql_mode | Keketatan validasi data (pertahankan mode ketat) |
Ubah satu parameter pada satu waktu dan ukur dampaknya.
Pemantauan
Perhatikan: penggunaan CPU/RAM/disk, jumlah koneksi, query lambat, replication lag, dan rasio hit buffer pool. Perintah berguna: SHOW PROCESSLIST;, SHOW ENGINE INNODB STATUS;, tabel performance_schema dan sys. Alat: Prometheus + mysqld_exporter + Grafana, atau Percona Monitoring and Management.
Kesalahan operasional yang sering terjadi
- Tidak ada backup yang teruji.
- Aplikasi memakai akun root.
- Port database terbuka ke internet.
- Mengabaikan charset sehingga data teks rusak.
- Transaksi panjang yang mengunci baris lama.
- Menjalankan
ALTER TABLEbesar di jam sibuk tanpa rencana. - Tidak memantau pertumbuhan disk hingga penuh.
Kesimpulan
MySQL dengan mesin InnoDB menyediakan transaksi, penguncian per baris, dan pemulihan crash yang andal. Pahami ACID dan isolasi untuk menjaga konsistensi, terapkan hak akses minimal, jadwalkan backup yang diuji, dan pantau server secara rutin. Dengan begitu MySQL menjadi fondasi yang kokoh, bukan sekadar kotak hitam di balik ORM.
Komentar (0)
Masuk / Daftar