Cara Menggunakan Indeks untuk Meningkatkan Performa MySQL

Beranda » Ular sanca » Cara Menggunakan Indeks untuk Meningkatkan Performa MySQL

Jika database MySQL atau MariaDB Anda mulai terasa lambat, pengindeksan pintar biasanya merupakan cara tercepat untuk menghasilkan peningkatan kinerja yang besar. Indeks yang dirancang dengan baik dapat mengubah kueri yang sangat lambat menjadi respons yang cepat, terutama ketika tabel Anda sudah menyimpan ratusan ribu atau jutaan baris.

Sisi sebaliknya adalah pengindeksan yang buruk atau berlebihan dapat secara diam-diam membunuh kinerja, meningkatkan penyimpanan dan membuat penulisan menjadi sulit, Jadi, Anda memerlukan model mental yang solid tentang cara kerja indeks, tipe indeks apa saja yang ditawarkan MySQL, bagaimana InnoDB menggunakan memori, dan kesalahan umum apa yang harus dihindari. Itulah inti dari panduan mendalam ini.

Apa itu indeks basis data di MySQL?

Indeks basis data adalah struktur data yang memungkinkan MySQL menemukan baris jauh lebih cepat daripada memindai seluruh tabel, sangat mirip dengan indeks di bagian belakang buku. Alih-alih memeriksa setiap baris satu per satu, MySQL mengikuti struktur padat dan teratur yang menunjuk langsung ke catatan yang cocok.

Ketika Anda menjalankan kueri tanpa indeks yang dapat digunakan, MySQL biasanya harus melakukan pemindaian tabel penuh, Membaca setiap baris untuk memeriksa apakah baris tersebut sesuai dengan kondisi dalam klausa WHERE atau JOIN Anda. Pada tabel besar, proses ini menjadi sangat lambat dan membutuhkan banyak I/O.

MySQL dan MariaDB terutama mengandalkan pengindeksan pohon seimbang (B‑Tree) untuk sebagian besar beban kerja, Di mana kunci disimpan dalam struktur pohon hierarkis. Struktur ini menjaga kunci tetap terurut dan memungkinkan MySQL menemukan nilai dalam waktu logaritmik dengan menelusuri pohon alih-alih membaca setiap baris dari disk.

Untuk membuatnya lebih konkret, bayangkan tabel Pelanggan di mana Anda sering mencari berdasarkan nama_depan = 'Ava', tetapi tidak ada indeks pada first_name. MySQL harus memeriksa first_name setiap baris hingga menemukan yang cocok, yang berarti waktu proses bertambah secara linear seiring dengan ukuran tabel.

Setelah Anda menambahkan indeks B‑Tree pada first_name, MySQL membangun pohon yang diurutkan dari semua nilai first_name beserta penunjuk baris, sehingga dapat melompati tingkat pohon, mengikuti cabang kiri atau kanan, hingga mencapai simpul daun yang merujuk ke semua baris di mana first_name = 'Ava'. Ia tidak perlu lagi memeriksa setiap baris dalam tabel.

Jenis indeks utama yang akan Anda gunakan di MySQL

MySQL menyediakan beberapa cara pengindeksan data, masing-masing dioptimalkan untuk pola kueri dan bentuk data yang berbeda, dan memahami pilihan ini membantu Anda memilih indeks yang tepat alih-alih menambahkannya secara membabi buta di mana-mana.

1. Indeks tingkat tunggal (sederhana)

Indeks kolom tunggal memetakan satu nilai kunci langsung ke satu atau lebih baris dalam tabel, dan merupakan gaya indeks paling dasar dan umum yang akan Anda gunakan sehari-hari.

Bayangkan kolom kunci utama seperti customer_id di tabel Pelanggan: kolom ini mengidentifikasi setiap baris secara unik, dan di balik itu semua MySQL memelihara indeks yang memetakan setiap customer_id ke lokasi baris terkait.

Indeks sederhana ini berfungsi dengan baik untuk tabel kecil atau sedang dan untuk kolom dengan kardinalitas rendah atau sedang, seperti status atau bendera kategori, selama kolom tersebut muncul di filter (WHERE) atau gabungan.

Gunakan indeks satu kolom ketika kueri biasanya memfilter pada satu bidang, misalnya WHERE customer_id = 123 atau WHERE status = 'active', dan Anda tidak memerlukan urutan penyaringan gabungan di beberapa kolom.

2. Indeks multi-kolom (multilevel/komposit)

Indeks komposit menggabungkan beberapa kolom menjadi satu struktur yang teratur, memungkinkan MySQL untuk secara efisien menyelesaikan kueri yang memfilter atau mengurutkan menggunakan beberapa bidang secara bersamaan.

Misalnya, pertimbangkan indeks yang didefinisikan pada (alamat, customer_id) di tabel Pelanggan, Di mana alamat dicantumkan terlebih dahulu dan customer_id dicantumkan kedua. MySQL kemudian dapat dengan cepat menemukan semua pelanggan yang tinggal di alamat tertentu dan, jika perlu, menelusurinya secara efisien berdasarkan urutan customer_id.

Organisasi hierarkis ini secara signifikan mengurangi perbandingan dibandingkan dengan memindai semua baris, yang terutama penting untuk kumpulan data yang lebih besar di mana Anda sering memfilter berdasarkan lebih dari satu kolom.

Indeks komposit sangatlah kuat, tetapi urutannya penting: indeks pada (alamat, id_pelanggan) dapat membantu pemfilteran kueri berdasarkan alamat saja atau berdasarkan alamat dan id_pelanggan, tetapi tidak akan digunakan sepenuhnya jika Anda hanya mencari berdasarkan id_pelanggan.

3. Indeks berkluster di InnoDB

Di InnoDB, indeks berkelompok mendefinisikan urutan logis indeks dan tata letak fisik baris pada disk, artinya data tabel itu sendiri disimpan dalam urutan indeks tersebut.

Berdasarkan desainnya, InnoDB menggunakan PRIMARY KEY sebagai indeks kluster, Jadi, saat Anda memilih kunci utama untuk suatu tabel, Anda sebenarnya mendefinisikan bagaimana baris-baris tersebut disimpan dan bagaimana indeks sekunder akan mereferensikan baris-baris tersebut.

Misalnya, jika customer_id adalah kunci utama, InnoDB menyimpan baris yang diurutkan berdasarkan customer_id, yang ideal ketika banyak kueri mengakses rentang pelanggan berdasarkan ID tersebut atau sering mencari pelanggan tunggal menggunakan pengenalnya.

Tata letak ini meningkatkan kinerja baca untuk kueri yang mengikuti urutan indeks berkelompok, tetapi itu juga berarti penyisipan atau pembaruan nilai yang berada di tengah rentang kunci bisa lebih mahal, karena InnoDB harus menjaga agar baris-baris tetap teratur secara fisik.

Memilih kunci utama yang stabil dan terus meningkat (seperti INT peningkatan otomatis atau kunci pengganti berbasis waktu) sering kali menghasilkan kinerja indeks berkelompok yang lebih baik, sedangkan kunci yang acak atau sering berubah dapat memecah struktur dan memperlambat penulisan.

4. Indeks sekunder (non-cluster)

Indeks sekunder adalah semua indeks lain dalam tabel InnoDB selain kunci utama yang dikelompokkan, dan menyediakan jalur pencarian cepat tambahan tanpa mengubah cara tabel itu sendiri diurutkan secara fisik.

Misalnya, menambahkan indeks pada email di tabel Pelanggan menciptakan struktur terpisah yang memetakan setiap email ke kunci utama baris terkait, Jadi MySQL dapat terlebih dahulu menemukan kunci utama melalui indeks sekunder, lalu mengambil baris lengkap dari indeks berkelompok.

Indeks sekunder fleksibel dan memungkinkan Anda mempercepat kueri pada beberapa kolom berbeda, yang penting ketika pola baca Anda bervariasi dan tidak semuanya dapat mengikuti kunci utama.

Namun, setiap indeks sekunder harus diperbarui pada INSERT, UPDATE dan DELETE, Jadi jika Anda menambahkan terlalu banyak, kinerja penulisan dan penggunaan penyimpanan akan menurun drastis.

5. B‑Tree, hash, teks lengkap dan indeks spasial

Di balik layar, MySQL mendukung beberapa struktur indeks di luar B‑Tree default, masing-masing ditujukan pada jenis data dan pola kueri tertentu.

• Indeks B‑Tree – default untuk InnoDB dan sebagian besar mesin penyimpanan, ideal untuk pencarian kesetaraan, pemindaian rentang, operasi ORDER BY dan GROUP BY.
• Indeks hash – digunakan oleh beberapa mesin atau sebagai struktur internal; bagus untuk perbandingan kesetaraan murni tetapi tidak untuk kueri rentang atau pemesanan.
• Indeks FULLTEXT – dioptimalkan untuk mencari konten teks, frasa, dan kata di seluruh kolom TEXT atau VARCHAR.
• Indeks SPASIAL – ditargetkan pada tipe data geografis, memungkinkan kueri efisien pada titik, garis, dan poligon.

Hal pentingnya adalah tidak ada satu pun jenis indeks yang sempurna untuk segala hal, Jadi Anda harus mencocokkan struktur indeks dengan sifat data Anda dan cara aplikasi Anda menanyakannya.

Membuat indeks di MySQL dengan contoh praktis

Membuat indeks di MySQL mudah dilakukan di tingkat SQL, tetapi dampaknya terhadap kinerja bisa sangat dramatis, Jadi ada baiknya melihat beberapa contoh konkret dan memahami apa fungsi masing-masing.

Mempersiapkan contoh tabel Pelanggan

Asumsikan Anda memulai dengan tabel Pelanggan sederhana tempat Anda menyimpan detail kontak dasar, seperti pengenal integer, nama, email, telepon, dan alamat.

Anda dapat membuat tabel seperti ini:

CREATE TABLE Customer (
customer_id INT PRIMARY KEY,
first_name VARCHAR(50),
last_name VARCHAR(50),
email VARCHAR(100),
phone_number VARCHAR(15),
address VARCHAR(255)
);

Setelah mendefinisikan tabel, Anda mengisinya dengan beberapa baris contoh, yang memberikan data aktual MySQL untuk dioptimalkan dan memungkinkan Anda menguji bagaimana indeks mengubah rencana kueri dan waktu eksekusi.

Menambahkan indeks sederhana

Misalkan Anda ingin mempercepat pencarian berdasarkan customer_id lebih jauh lagi, mungkin karena kunci utama tidak didefinisikan pada awalnya atau Anda bekerja dengan mesin atau skema lama yang berbeda.

Anda dapat membuat indeks dasar seperti ini:

CREATE INDEX idx_customer_id ON Customer(customer_id);

Setelah perintah ini selesai, MySQL mengakui pembuatan indeks, dan kueri dengan WHERE customer_id = ? atau gabungan sederhana pada kolom tersebut menjadi jauh lebih cepat, karena dapat menggunakan struktur baru, alih-alih pemindaian penuh.

Membuat indeks komposit

Ketika kueri Anda difilter berdasarkan lebih dari satu kolom pada satu waktu, sering kali masuk akal untuk membuat indeks komposit yang menyimpan nilai-nilai tersebut bersama-sama dalam urutan yang ditentukan.

Misalnya, untuk mempercepat penelusuran berdasarkan alamat dan customer_id, Anda dapat menjalankan:

CREATE INDEX idx_address_customer_id
ON Customer(address, customer_id);

Indeks ini sangat efektif untuk kueri seperti WHERE address = ? AND customer_id = ?, atau untuk pemindaian yang mengelompokkan atau mengurutkan berdasarkan alamat dan kemudian berdasarkan customer_id, karena MySQL dapat mengandalkan pengurutan yang ada di dalam indeks.

Indeks non-cluster pada email

Bidang email adalah kandidat klasik untuk indeks sekunder, karena cenderung unik atau sangat selektif dan sering digunakan untuk login atau pencarian akun.

Anda dapat menambahkan indeks sekunder pada email dengan:

CREATE INDEX idx_email ON Customer(email);

Setelah ini, MySQL tidak perlu lagi memindai seluruh tabel Pelanggan untuk menyelesaikan WHERE email = ”, Ia hanya menelusuri indeks, menemukan kunci yang cocok, lalu membaca baris terkait menggunakan referensi kunci utama.

Mencakup indeks untuk pembacaan yang lebih cepat

Indeks penutup adalah indeks yang mencakup semua kolom yang dibutuhkan oleh suatu kueri, sehingga MySQL dapat menjawab permintaan sepenuhnya dari struktur indeks tanpa menyentuh tabel dasar (juga dikenal sebagai pemindaian indeks saja).

Bayangkan Anda sering menjalankan kueri yang hanya membutuhkan nama_depan dan nama_belakang:

CREATE INDEX idx_covering_name
ON Customer(first_name, last_name);

Untuk kueri yang hanya memilih dua bidang tersebut dan memfilternya dengan tepat, MySQL dapat membaca langsung dari idx_covering_name, mengurangi I/O disk dan meningkatkan latensi, terutama pada kumpulan data besar.

Strategi dan praktik terbaik pengoptimalan indeks

Melempar indeks di setiap kolom adalah cara yang pasti akan merusak kinerja, bukan membantunya, jadi Anda memerlukan beberapa prinsip yang jelas untuk merancang, memantau, dan memangkas indeks dari waktu ke waktu.

1. Pilih kolom yang tepat untuk diindeks

Prioritaskan kolom yang sering muncul di klausa WHERE, JOIN, ORDER BY atau GROUP BY, karena merekalah yang paling diuntungkan dari pencarian cepat atau akses terurut.

Kolom yang sebagian besar berisi nilai unik atau sangat selektif merupakan kandidat indeks yang sangat baik, karena MySQL dapat dengan cepat mempersempit ke sejumlah kecil baris, seringkali hanya satu.

Di sisi lain, pengindeksan kolom dengan kardinalitas sangat rendah (seperti bendera boolean) mungkin tidak banyak membantu, karena mesin masih harus memindai banyak baris untuk setiap kunci indeks, yang membatasi manfaatnya.

2. Buatlah indeks sesingkat dan seramping mungkin

Kunci indeks yang besar menghabiskan lebih banyak memori dan ruang disk dan memperlambat setiap operasi penulisan, Jadi, Anda biasanya ingin membuat kolom yang diindeks sepadat mungkin.

Untuk teks panjang atau bidang dengan panjang variabel, pertimbangkan untuk mengindeks hanya awalan jika cukup untuk membedakan nilai, misalnya mengindeks 20 karakter pertama dari bidang 200 karakter jika itu cukup untuk kueri Anda.

Menggunakan tipe numerik alih-alih bidang teks besar untuk gabungan dan filter juga meningkatkan efisiensi indeks, karena bilangan bulat dan nilai berukuran tetap lebih murah untuk dibandingkan dan disimpan.

3. Hindari pengindeksan berlebihan

Setiap indeks tambahan adalah sesuatu yang harus diperbarui MySQL pada INSERT, UPDATE dan DELETE, yang berarti pembuatan indeks yang ceroboh dapat memperlambat beban kerja penulisan yang berat secara drastis.

Pengindeksan berlebih juga membuang-buang penyimpanan dan dapat membingungkan pengoptimal jika terdapat beberapa indeks serupa, membuat MySQL lebih sulit memilih rencana yang benar-benar optimal.

Aturan praktis yang baik adalah membuat indeks hanya ketika Anda dapat mengidentifikasi pertanyaan konkret yang akan bermanfaat, lalu verifikasi dengan EXPLAIN bahwa kueri tersebut benar-benar menggunakan indeks baru.

4. Hapus indeks yang berlebihan dan tidak digunakan

Sangat umum untuk menemukan skema produksi dengan banyak indeks redundan yang tidak ada yang ingat telah membuatnya, terutama setelah beberapa iterasi pengembangan.

Anda harus secara berkala meninjau indeks mana yang jarang atau tidak pernah digunakan oleh kueri, memanfaatkan skema kinerja MySQL atau alat pemantauan eksternal untuk mengumpulkan statistik penggunaan.

Setelah Anda mengidentifikasi indeks yang benar-benar tidak diperlukan, membuangnya dengan aman dapat meningkatkan kinerja penulisan dan penyimpanan kosong:

DROP INDEX idx_unnecessary_index ON Customer;

Selalu uji dampak penghapusan indeks di lingkungan pementasan atau pengujian terlebih dahulu, terutama untuk sistem lama di mana kueri tersembunyi mungkin bergantung padanya.

5. Analisis pola kueri sebelum mengindeks

Menambahkan indeks secara membabi buta tanpa memahami perilaku kueri adalah salah satu anti-pola terbesar, dan sering kali menyebabkan penulisan lambat dan tidak ada peningkatan pembacaan yang nyata.

Mulailah dengan menangkap kueri yang lambat dan kueri frekuensi tinggi, lalu periksa dengan cermat, konsultasikan dengan panduan optimasi kueri MySQL lengkap, memberikan perhatian khusus pada kondisi WHERE, kolom JOIN dan klausa pengurutan atau pengelompokan.

Gunakan EXPLAIN untuk melihat bagaimana MySQL berencana untuk mengeksekusi setiap query dan memeriksa apakah menggunakan indeks atau kembali ke pemindaian tabel penuh, dan menyempurnakan strategi pengindeksan Anda sebagaimana mestinya.

Kumpulan buffer InnoDB dan sisi memori kinerja indeks

Indeks tidak hanya ada di disk: InnoDB sangat bergantung pada RAM, melalui kumpulan buffer, untuk menyimpan data dan halaman indeks, dan lapisan memori ini memiliki efek besar pada kinerja dunia nyata.

Kumpulan buffer InnoDB adalah wilayah memori besar tempat MySQL menyimpan data tabel, halaman indeks, baris yang dimodifikasi yang menunggu untuk dihapus, dan beberapa struktur internal seperti indeks hash adaptif; lihat ikhtisar sistem penyimpanan untuk pertimbangan terkait.

Pada layanan terkelola seperti Cloud SQL, ukuran kumpulan buffer default biasanya ditetapkan sekitar 70-75% dari memori instans, tetapi Anda dapat dan sering kali harus menyesuaikannya tergantung pada beban kerja dan RAM yang tersedia.

Tujuannya adalah untuk membuat kumpulan buffer cukup besar sehingga data dan halaman indeks yang paling sering diakses tetap berada di memori, sambil tetap menyisakan ruang untuk buffer koneksi, tabel performance_schema, dan overhead MySQL lainnya.

Anda dapat memantau berapa banyak pembacaan yang dilayani dari disk dibandingkan dari kumpulan buffer, dan jika Anda melihat banyak pembacaan disk relatif terhadap buffer hits, peningkatan innodb_buffer_pool_size (dan memori instans) dapat secara signifikan mempercepat kueri pembacaan yang bergantung pada indeks.

Skema, kueri, dan skrip: gambaran kinerja MySQL yang lebih besar

Penyetelan indeks tidak terjadi begitu saja; desain skema, struktur kueri, dan kode aplikasi semuanya berperan dalam seberapa baik kinerja MySQL, jadi ada baiknya menyentuh praktik terbaik di sekitarnya.

1. Rancang model relasional yang masuk akal

Menghabiskan waktu di awal untuk merancang skema relasional yang bersih dengan tabel, bidang, dan hubungan yang sesuai memberikan keuntungan besar dalam pemeliharaan yang lebih mudah dan kinerja yang lebih dapat diprediksi.

Mengidentifikasi entitas, propertinya dan bagaimana hubungannya satu sama lain, kemudian menerjemahkannya ke dalam tabel, kunci utama, kunci asing dan indeks pendukung, bertujuan pada tingkat normalisasi yang menghindari redundansi tanpa masuk ke kondisi ekstrem yang terlalu dinormalisasi.

Kunci utama secara unik mengidentifikasi setiap baris, sementara kunci asing mengekspresikan hubungan antar tabel, dan keduanya biasanya memerlukan indeks karena keduanya muncul terus-menerus dalam gabungan dan kendala.

2. Pilih jenis bidang dengan bijak

Jenis bidang memiliki dampak langsung terhadap kinerja, terutama ketika merupakan bagian dari indeks, Jadi, ada baiknya untuk bersikap lebih intensional daripada terpaku pada tipe generik.

Gunakan tipe data yang konsisten untuk jenis informasi yang sama di seluruh tabel, karena ini menyederhanakan penggabungan dan memungkinkan MySQL melakukan perbandingan secara lebih efisien.

Lebih memilih tipe dengan panjang tetap (seperti CHAR atau tipe numerik dengan ukuran tetap) jika sesuai dibandingkan dengan bidang dengan panjang variabel yang sangat besar, dan hindari penggunaan TEXT atau BLOB untuk nilai yang rutin Anda filter atau gabungkan.

Jika memungkinkan, nyatakan kolom sebagai NOT NULL, karena menangani bidang yang dapat bernilai null dapat memperlambat beberapa operasi dan mempersulit penggunaan indeks.

3. Jaga agar meja tetap kompak dan rapi

Tabel ramping adalah tabel yang lebih cepat, karena lebih sedikit data yang harus dipindahkan melalui memori dan disk, terutama ketika kueri kompleks menyentuh beberapa baris atau gabungan.

Jika Anda menggunakan opsi ROW_FORMAT, pilih baris berukuran tetap jika masuk akal, karena dapat membuat pembacaan berurutan lebih efisien dibandingkan dengan format baris yang sangat bervariasi.

Tinjau secara berkala apakah catatan lama dapat diarsipkan atau dihapus, menjaga set kerja panas Anda sekecil mungkin untuk efisiensi cache dan kinerja indeks yang lebih baik.

Setelah penghapusan berat atau banyak perubahan struktural, menjalankan OPTIMIZE TABLE dapat membantu mengatur ulang penyimpanan dan meningkatkan pola I/O, meskipun Anda harus berhati-hati dengan tabel produksi besar karena implikasi penguncian dan waktu henti.

4. Tulis kueri dengan mempertimbangkan kinerja

Bahkan dengan indeks yang bagus, SQL yang ditulis dengan buruk dapat merusak kinerja, jadi desain kueri harus berjalan beriringan dengan desain indeks.

Hindari SELECT * dalam kueri produksi dan cantumkan secara eksplisit hanya kolom yang Anda perlukan, mengurangi jumlah data yang ditransfer dan jumlah indeks atau halaman data yang harus dibaca MySQL.

Berhati-hatilah dengan pola LIKE yang dimulai dengan karakter pengganti (misalnya '%term'), karena biasanya mencegah penggunaan indeks B-Tree normal; untuk pencarian teks berat, indeks FULLTEXT biasanya merupakan pilihan yang lebih baik.

Gunakan GROUP BY, ORDER BY dan HAVING hanya jika benar-benar diperlukan, dan pastikan kolom yang terlibat diindeks dengan benar atau cocok dengan kolom utama indeks komposit bila memungkinkan.

Manfaatkan EXPLAIN untuk memeriksa bagaimana MySQL berencana menjalankan kueri, mencari tanda seperti “type = ALL” atau “rows” yang sangat tinggi, yang biasanya menunjukkan pemindaian penuh dan penggunaan indeks yang buruk.

5. Optimalkan penyisipan dan perilaku tingkat skrip

Selain SQL mentah, cara skrip aplikasi Anda terhubung dan berinteraksi dengan MySQL sangat penting bagi responsivitas keseluruhan, terutama dalam skala besar.

Sisipan batch biasanya lebih efisien daripada banyak sisipan baris tunggal, misalnya menggunakan INSERT INTO table (col1, col2) VALUES (…), (…), (…); sehingga MySQL dapat memproses beberapa baris sekaligus dan mengikuti Dasar-dasar transaksi MySQL untuk pencampuran yang tepat.

Membagi hasil kueri menjadi beberapa bagian menggunakan LIMIT daripada memuat set hasil yang besar ke dalam memori atau mendorong semuanya ke klien sekaligus, yang mengurangi waktu muat dan penggunaan sumber daya.

Perkenalkan lapisan caching (cache dalam memori, cache tingkat aplikasi, penyimpanan sesi) untuk data yang jarang berubah tetapi sering dibaca, memindahkan pembacaan berulang dari MySQL dan membuat sistem Anda lebih tangguh di bawah beban puncak.

Minimalkan koneksi database yang tidak diperlukan dan jaga agar masa pakai koneksi tetap wajar, sering kali melalui pengumpulan koneksi dan dengan melakukan pemrosesan berat setelah Anda mengambil data, bukan saat koneksi terbuka.

Kesalahan umum dalam pengindeksan dan cara menghindarinya

Penyalahgunaan indeks dapat secara diam-diam menimbulkan masalah kinerja yang besar, Jadi ada baiknya mengetahui kendala yang umum terjadi dan cara mengatasinya.

Pengindeksan berlebih

Menambahkan indeks ke setiap kolom “untuk berjaga-jaga” adalah kesalahan klasik yang sering dilakukan pemula, karena setiap indeks tambahan memperlambat semua operasi penulisan dan menghabiskan penyimpanan tambahan.

Anda harus memangkas daftar indeks sesuai dengan kebutuhan kueri Anda yang sebenarnya, menggunakan log kueri dan alat kinerja untuk memahami indeks mana yang benar-benar berfungsi dan mana yang tidak berfungsi sama sekali.

Kurangnya indeks atau hilangnya indeks penting

Kesalahan yang sebaliknya adalah tidak mengindeks kolom-kolom yang penting, terutama kunci gabungan dan bidang yang sering difilter, yang memaksa MySQL melakukan pemindaian tabel yang mahal.

Analisis log kueri lambat dan kueri teratas secara berkala, dan membuat indeks yang ditargetkan pada kolom yang muncul berulang kali dalam klausa WHERE dan JOIN.

Jenis indeks salah atau urutan kolom salah

Penggunaan struktur indeks yang tidak tepat dapat membuat kueri menjadi lebih lambat, bukannya lebih cepat, seperti mengharapkan pola akses seperti hash dari B‑Tree untuk beban kerja tertentu atau sebaliknya.

Dengan indeks komposit, kesalahan urutan kolom adalah masalah lain yang sering terjadi, karena MySQL hanya sepenuhnya menggunakan bagian paling kiri indeks untuk banyak tipe kueri.

Statistik indeks basi dan kurangnya pemeliharaan

Statistik indeks memandu keputusan pengoptimal, dan ketika statistik tersebut menjadi usang, MySQL mungkin memilih rencana kueri yang buruk yang tidak mencerminkan distribusi data saat ini.

Menjalankan ANALYZE TABLE dan, jika sesuai, OPTIMIZE TABLE secara teratur membantu menjaga statistik dan tata letak fisik tetap dalam bentuk, terutama pada kumpulan data yang berubah dengan cepat.

Mengabaikan pemantauan dan MENJELASKAN keluaran

Mendesain indeks tanpa memeriksa bagaimana indeks tersebut digunakan adalah resep untuk tebak-tebakan, dan tebak-tebakan jarang menghasilkan kinerja berkelanjutan.

Gunakan EXPLAIN untuk melihat indeks mana yang dipilih untuk kueri, berapa banyak baris yang diperkirakan, dan apakah pemindaian rentang atau hanya indeks yang digunakan, lalu sesuaikan skema atau kueri Anda jika perencana jelas tidak dapat memanfaatkan indeks secara efisien.

Tips manajemen indeks MySQL untuk kinerja jangka panjang

Menjaga MySQL tetap cepat dari waktu ke waktu adalah proses pengukuran, penyempurnaan, dan pembersihan yang berkelanjutan, terutama saat data Anda bertumbuh dan pola kueri berkembang.

• Pilih indeks yang selaras dengan pola kueri dunia nyata, berfokus pada kolom yang digunakan untuk memfilter, menggabungkan, dan mengurutkan.
• Pertimbangkan indeks komposit ketika beberapa kolom selalu ditanyakan bersama, memilih kolom yang paling selektif atau paling sering difilter terlebih dahulu.
• Memantau ukuran indeks dan kinerja penulisan, dan menghapus atau menggabungkan indeks yang tumpang tindih ketika indeks tersebut tidak lagi memberikan manfaat yang jelas.
• Menganalisis kueri secara berkala menggunakan EXPLAIN dan memperlambat log kueri, menyetel SQL dan indeks saat beban kerja Anda berubah.

Ketika Anda mendekati pengindeksan sebagai proses penyetelan yang berkelanjutan dan didorong oleh data daripada tugas satu kali, Anda dapat membuat MySQL menangani beban kerja yang lebih besar, lebih banyak pengguna, dan kueri yang lebih kompleks tanpa terhenti.