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
Lepaskan: 2024-12-16 05:49:10
asal
170 orang telah melayarinya

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;
Salin selepas log masuk

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;
Salin selepas log masuk

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"
        }
    }
]
Salin selepas log masuk

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!

sumber:php.cn
Kenyataan Laman Web ini
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
Tutorial Popular
Lagi>
Muat turun terkini
Lagi>
kesan web
Kod sumber laman web
Bahan laman web
Templat hujung hadapan