Rumah >pangkalan data >tutorial mysql >Konfigurasi Indeks yang manakah (Lajur Julat Pertama lwn Lajur Kardinaliti Rendah Didahulukan) Adakah Optimum untuk Pertanyaan Julat pada Lajur Kardinaliti Tinggi dan Rendah?

Konfigurasi Indeks yang manakah (Lajur Julat Pertama lwn Lajur Kardinaliti Rendah Didahulukan) Adakah Optimum untuk Pertanyaan Julat pada Lajur Kardinaliti Tinggi dan Rendah?

DDD
DDDasal
2024-12-16 05:49:10176semak imbas

Which Index Configuration (Range Column First vs. Low Cardinality Column First) Is Optimal for Range Queries on High and Low Cardinality Columns?

Konfigurasi Indeks manakah yang Optimum apabila Bekerja dengan Pertanyaan Julat yang Melibatkan Lajur Kardinaliti Tinggi dan Rendah?

Dalam senario yang diberikan, kami mempunyai jadual 'fail' dengan kunci utama pada 'did' dan 'filename', dan dua indeks tambahan: 'fe' pada 'filetime' dan 'ext', dan 'ef' pada 'ext' dan 'filetime'. Pertanyaan kami melibatkan menapis baris berdasarkan kedua-dua 'ext' dan 'filetime' menggunakan keadaan julat.

Mari teroka konfigurasi indeks yang lebih cekap untuk pertanyaan ini.

Menilai Pilihan Indeks

Untuk menentukan indeks optimum, kita boleh menganalisis potensi penggunaan indeks dan anggaran kos menggunakan JELASKAN:

Memaksa fe (lajur julat dahulu):

EXPLAIN SELECT COUNT(*), AVG(fsize)
FROM files FORCE INDEX(fe)
WHERE ext = 'gif' AND filetime >= '2015-01-01' AND filetime < '2015-01-01' + INTERVAL 1 MONTH;

Memaksa ef (lajur kardinaliti rendah dahulu):

EXPLAIN SELECT COUNT(*), AVG(fsize)
FROM files FORCE INDEX(ef)
WHERE ext = 'gif' AND filetime >= '2015-01-01' AND filetime < '2015-01-01' + INTERVAL 1 MONTH;

Analisis

JELASKAN mencadangkan bahawa menggunakan 'ef' (lajur kardinaliti rendah dahulu) menghasilkan pelan pelaksanaan yang lebih cekap berbanding dengan 'fe'. Ini kerana 'ef' membolehkan pengoptimum menapis baris menggunakan kedua-dua lajur indeks, membawa kepada anggaran kos yang lebih rendah.

Jejak Pengoptimum

Surih Pengoptimum menyediakan pandangan tambahan tentang penilaian indeks proses:

"potential_range_indices": [
    {
        "index": "fe",
        "usable": true
    },
    {
        "index": "ef",
        "usable": true
    }
],
"analyzing_range_alternatives": {
    "range_scan_alternatives": [
        {
            "index": "fe",
            "ranges": [...],
            "index_only": false,
            "rows": 16684,
            "cost": 20022
        },
        {
            "index": "ef",
            "ranges": [...],
            "index_only": false,
            "rows": 538,
            "cost": 646.61
        }
    ]
},
"attached_conditions_computation": [
    {
        "access_type_changed": {
            "table": "`files`",
            "index": "ef",
            "old_type": "ref",
            "new_type": "range",
            "cause": "uses_more_keyparts"
        }
    }
]

Kesimpulan

Surian Pengoptimum mengesahkan bahawa:

  • "fe" (lajur julat dahulu) hanya menggunakan lajur pertama untuk penapisan.
  • "ef" (lajur kardinaliti rendah dahulu) memanfaatkan kedua-dua lajur indeks untuk penapisan.
  • Pengoptimum mengutamakan penggunaan lajur yang terlibat dalam keadaan julat, tanpa mengira kardinaliti, semasa membina indeks komposit.
  • Kardinaliti kurang relevan untuk indeks komposit dalam senario pertanyaan jenis ini.

Oleh itu, mempertimbangkan kedua-dua keluaran EXPLAIN dan Surih pengoptimum, konfigurasi indeks optimum ialah ef (ext, masa fail) untuk pertanyaan yang melibatkan kedua-dua keadaan julat ext dan masa fail. Dengan meletakkan lajur kardinaliti rendah di hadapan dalam indeks, kami membolehkan pengoptimum menggunakan kedua-dua lajur dengan berkesan, menghasilkan pelan pelaksanaan yang lebih cekap.

Atas ialah kandungan terperinci Konfigurasi Indeks yang manakah (Lajur Julat Pertama lwn Lajur Kardinaliti Rendah Didahulukan) Adakah Optimum untuk Pertanyaan Julat pada Lajur Kardinaliti Tinggi dan Rendah?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!

Kenyataan:
Kandungan artikel ini disumbangkan secara sukarela oleh netizen, dan hak cipta adalah milik pengarang asal. Laman web ini tidak memikul tanggungjawab undang-undang yang sepadan. Jika anda menemui sebarang kandungan yang disyaki plagiarisme atau pelanggaran, sila hubungi admin@php.cn