MySQL System Database

Saat kita menjalankan SHOW DATABASES, selain database aplikasi ada empat nama yang selalu muncul: mysql, information_schema, performance_schema, dan sys. Keempatnya adalah database sistem — tempat server MySQL menyimpan catatan tentang dirinya sendiri, mulai dari daftar akun beserta hak aksesnya, struktur seluruh tabel yang pernah dibuat, hingga hasil pengukuran performa internal. Memahami isi dan cara membacanya adalah bekal penting: banyak pertanyaan administrasi (“akun apa saja yang ada?”, “tabel mana yang memakai storage engine tertentu?”) paling cepat dijawab dengan query langsung ke database sistem. Chapter ini membuka satu per satu keempat database tersebut, lalu menutup dengan satu aturan emas yang menjaganya tetap konsisten.

Empat Warga Sistem dan Perannya #

Keempat database sistem punya pembagian kerja yang tegas dan saling melengkapi:

Database mysql adalah satu-satunya yang menyimpan data secara fisik seperti database aplikasi. Tiga sisanya lebih tepat dibayangkan sebagai jendela: information_schema membangun isinya dari data dictionary setiap kali kita meng-query-nya, performance_schema menampung angka pengukuran yang terus diperbarui di memori, dan sys hanyalah lapisan view yang merangkai dua jendela tadi menjadi laporan berbahasa manusia.

Database mysql: Katalog dan Grant Tables #

Bagian paling terkenal dari database mysql adalah grant tables — kumpulan tabel yang menentukan siapa boleh masuk dan boleh melakukan apa. Tiga tabel utamanya bekerja berlapis: mysql.user menyimpan satu baris per akun beserta privilege level server, mysql.db menambah privilege level database, dan mysql.tables_priv menambah privilege level tabel. Kita baca ketiganya dengan SELECT kolom-kolom yang aman ditampilkan:

SELECT user, host, plugin FROM mysql.user ORDER BY user, host;
SELECT Host, Db, User FROM mysql.db;
SELECT Host, Db, User, Table_name, Table_priv FROM mysql.tables_priv;

Output yang Dihasilkan:

+------------------+-----------+-----------------------+
| user             | host      | plugin                |
+------------------+-----------+-----------------------+
| mysql.infoschema | localhost | caching_sha2_password |
| mysql.session    | localhost | caching_sha2_password |
| mysql.sys        | localhost | caching_sha2_password |
| root             | localhost | caching_sha2_password |
+------------------+-----------+-----------------------+
4 rows in set (0.00 sec)

+-----------+--------------------+---------------+
| Host      | Db                 | User          |
+-----------+--------------------+---------------+
| localhost | performance_schema | mysql.session |
| localhost | sys                | mysql.sys     |
+-----------+--------------------+---------------+
2 rows in set (0.00 sec)

+-----------+-------+---------------+------------+------------+
| Host      | Db    | User          | Table_name | Table_priv |
+-----------+-------+---------------+------------+------------+
| localhost | mysql | mysql.session | user       | Select     |
| localhost | sys   | mysql.sys     | sys_config | Select     |
+-----------+-------+---------------+------------+------------+
2 rows in set (0.00 sec)

Empat akun di mysql.user berasal dari instalasi standar: root milik kita, sementara mysql.infoschema, mysql.session, dan mysql.sys adalah akun internal yang dipakai view-view sistem — kolom plugin menunjukkan semuanya mengautentikasi lewat caching_sha2_password. Tabel mysql.db dan mysql.tables_priv terlihat berisi dua baris yang saling berkaitan: akun internal mysql.sys diberi hak SELECT atas database sys, dan mysql.session diberi hak SELECT atas tabel mysql.user — persis hak minimum yang dibutuhkan view sistem untuk bekerja.

information_schema: Metadata yang Di-query #

Database information_schema menjawab pertanyaan “apa saja yang ada di server ini”. Isinya bukan salinan data, melainkan metadata yang dibangun langsung dari data dictionary pada saat query berjalan — mendrop tabel apa pun di sini tidak mungkin, karena tidak ada file yang dihapus. Kita siapkan database latihan kecil lalu membaca strukturnya:

DROP DATABASE IF EXISTS belajar_admin;
CREATE DATABASE belajar_admin;
USE belajar_admin;
CREATE TABLE produk (id INT PRIMARY KEY, nama VARCHAR(40), harga DECIMAL(10,2));
CREATE TABLE pesanan (id INT PRIMARY KEY, produk_id INT, jumlah INT);
INSERT INTO produk VALUES (1, 'Kopi Arabika', 85000.00);

Output yang Dihasilkan:

Query OK, 0 rows affected, 1 warning (0.00 sec)

Query OK, 1 row affected (0.00 sec)

Database changed
Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 1 row affected (0.00 sec)

Sekarang kita tanyakan seluruh tabel milik belajar_admin beserta atributnya:

SELECT TABLE_NAME, TABLE_TYPE, ENGINE, TABLE_COLLATION
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'belajar_admin'
ORDER BY TABLE_NAME;

Output yang Dihasilkan:

+------------+------------+--------+--------------------+
| TABLE_NAME | TABLE_TYPE | ENGINE | TABLE_COLLATION    |
+------------+------------+--------+--------------------+
| pesanan    | BASE TABLE | InnoDB | utf8mb4_0900_ai_ci |
| produk     | BASE TABLE | InnoDB | utf8mb4_0900_ai_ci |
+------------+------------+--------+--------------------+
2 rows in set (0.00 sec)

Hasilnya memuat kedua tabel kita dengan ENGINE InnoDB dan collation utf8mb4_0900_ai_ci — nilai yang diwarisi dari konfigurasi server di chapter pertama section ini. Perhatikan dua hal khas information_schema: nama kolom ditulis huruf besar (TABLE_NAME, bukan table_name), dan hasilnya bisa disaring dengan WHERE serta diurutkan dengan ORDER BY layaknya query biasa — hal yang tidak bisa dilakukan SHOW TABLES. Kedalaman metadatanya sampai level kolom:

SELECT COLUMN_NAME, DATA_TYPE, COLUMN_KEY
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'belajar_admin' AND TABLE_NAME = 'produk'
ORDER BY ORDINAL_POSITION;

Output yang Dihasilkan:

+-------------+-----------+------------+
| COLUMN_NAME | DATA_TYPE | COLUMN_KEY |
+-------------+-----------+------------+
| id          | int       | PRI        |
| nama        | varchar   |            |
| harga       | decimal   |            |
+-------------+-----------+------------+
3 rows in set (0.00 sec)

Query di atas membedah tabel produk dari sisi metadata: tiga kolom berturut-turut dengan tipenya masing-masing, dan kolom id ditandai PRI sebagai primary key. Semua yang ditampilkan SHOW TABLES, SHOW COLUMNS, atau SHOW INDEX sebenarnya berhulu ke sumber yang sama; keunggulan information_schema adalah kemampuan memfilter, menggabungkan, dan mengagregasi metadata dalam satu query.

performance_schema: Instrumen yang Bisa Dimatikan #

Database performance_schema adalah black box flight recorder MySQL: sensor yang merekam kapan saja sebuah thread menunggu disk, kunci, atau mutex, berapa lama setiap statement berjalan, dan ke memori mana saja alokasi mengalir. Pengukuran sepresisi ini memakan sumber daya, sehingga server uji kita sengaja menjalankannya dalam keadaan mati:

SHOW VARIABLES LIKE 'performance_schema';
SELECT COUNT(*) AS thread_terlihat FROM performance_schema.threads;

Output yang Dihasilkan:

+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| performance_schema | OFF   |
+--------------------+-------+
1 row in set (0.00 sec)

+-----------------+
| thread_terlihat |
+-----------------+
|               0 |
+-----------------+
1 row in set (0.00 sec)

Nilai OFF pada performance_schema menjelaskan kenapa hasil query kedua nol: skema dan tabelnya masih dapat ditanyai (tidak ada error), namun instrumen perekamnya tidak pernah dinyalakan sehingga tidak ada data yang mengalir. Variabel ini ber-scope global dan tidak dinamis — menghidupkannya menuntut opsi startup performance_schema=ON diikuti restart, keputusan yang di server produksi lazim diambil karena manfaat datanya jauh melampaui overheadnya (umumnya di bawah beberapa persen).

sys: Lapisan Kenyamanan #

Membaca tabel performance_schema mentah-mentah butuh kebiasaan: kolom-kolomnya berisi angka pikosecond dan ID instrument yang harus digabung-gabungkan sendiri. Database sys hadir sebagai jawaban: 100-an view dengan nama ramah seperti innodb_buffer_stats_by_table atau statements_with_runtimes_in_95th_percentile, semuanya merangkai performance_schema dan information_schema menjadi laporan siap baca:

SHOW TABLES FROM sys LIKE 'version';
SELECT sys_version, mysql_version FROM sys.version;

Output yang Dihasilkan:

+-------------------------+
| Tables_in_sys (version) |
+-------------------------+
| version                 |
+-------------------------+
1 row in set (0.00 sec)

+-------------+---------------+
| sys_version | mysql_version |
+-------------+---------------+
| 2.1.3       | 8.4.11        |
+-------------+---------------+
1 row in set (0.00 sec)

View sys.version mencantumkan versi skema sys itu sendiri (2.1.3) dan versi server yang menjalankannya — informasi kecil yang menegaskan seluruh set view ini memang dibawa oleh MySQL 8.4.11 kita. Karena sys dibangun di atas performance_schema, matinya instrumen di chapter sebelumnya ikut menjandralisasi sebagian besar isinya: view berbasis pengukuran runtime seperti sys.processlist mengembalikan nol baris, sementara view yang membaca information_schema tetap hidup. Sifat inilah yang membuat sys menjadi pintu masuk diagnosis yang nyaman: mulai dari view bernama jelas, lalu turun ke performance_schema bila butuh detail mentah.

Referensi #

• The INFORMATION_SCHEMA Database — MySQL 8.4 Reference Manual
• The sys Schema — MySQL 8.4 Reference Manual
• INFORMATION_SCHEMA Tables Reference — MySQL 8.4 Reference Manual
• Privileges Provided by MySQL — MySQL 8.4 Reference Manual

Database sistem menjawab “apa yang ada” di dalam server. Namun administrasi juga membutuhkan jawaban atas “apa yang telah terjadi” — kejadian error saat startup, koneksi yang datang pergi, query yang lewat. Semua rekam jejak itu ditulis ke berbagai file dan tabel log, topik chapter berikutnya.