MySQL Spaltenindex funktioniert nicht (wie erwartet)?

Question

Ich habe eine Tabelle wie diese

CREATE TABLE IF NOT EXISTS `tbl_folder` (
    `id` int(11) NOT NULL AUTO_INCREMENT, 
    `owner_userid` int(11) NOT NULL, 
    `name` varchar(63) NOT NULL, 
    `description` text NOT NULL, 
    `visibility` tinyint(4) NOT NULL DEFAULT '2', 
    `num_items` int(11) NOT NULL DEFAULT '0', 
    `num_subscribers` int(11) NOT NULL DEFAULT '0', 
    PRIMARY KEY (`id`), 
    KEY `owner_userid` (`owner_userid`), 
    KEY `vis_sub_item` (`visibility`,`num_subscribers`,`num_items`) 
) ENGINE=InnoDB 

da ich einen Index auf Sicht, NUM_SUBSCRIBERS und NUM_ITEMS haben, erwarte ich, dass nur die ersten 15 Zeilen müssen nur an, sondern betrachtet werden, sagt ERKLÄREN 55856 Zeilen. Irgendeine Idee? Dank

EXPLAIN SELECT t.id, name, description, owner_userid, num_items, num_subscribers 
FROM `tbl_folder` `t` 
WHERE visibility =2 
ORDER BY `t`.`num_subscribers` DESC , `t`.`num_items` DESC 
LIMIT 15 

id select_type table type possible_keys key key_len ref rows Extra 
1 SIMPLE t ref vis_sub_item vis_sub_item 1 const 55856 Using where 

Answer 1

Ihr 3-Feld-Index sieht gut aus und die EXPLAIN ist vielversprechend.

Obwohl es "55856 Zeilen" sagt, das ist nur eine Schätzung von EXPLAIN zur Verfügung gestellt.

Seit key_len =1 wissen Sie, dass es das erste Byte Ihres zusammengesetzten Index als Gleichheit/Referenz verwendet.

Da es keine filesort in Ihrem Extra Feld erwähnt ist, wissen Sie, dass die ORDER BY/Sortieranlagen ist durch den Index gehandhabt wird.

Wenn Sie Ihre Sitzungsstatistik überprüfen, haben Sie eine bessere Vorstellung davon, wie viele Zeilen tatsächlich gelesen werden.

Side Gedanken:

Da Sie wissen, dass Sie letztlich Scheibe geht zu treffen Ihre Zeilen abzurufen, wenn 99% Ihrer Daten visibility=2 hat (nur spekulieren), dann würden Sie wahrscheinlich als gleich gut erhalten/schnelle Ergebnisse mit einem zusammengesetzten Index nur auf num_subscribers & num_items. Oder wohl so gut/schnell, wenn Sie einen einzigen Index auf num_subscribers haben, abhängig von seiner Kardinalität/Einzigartigkeit.

Answer 2

Ich glaube nicht, dass EXPLAIN am OFFSET oder LIMIT Klausel sieht. EXPLAIN soll angeben, wie die Abfrage ausgeführt würde, welche Schlüssel sie verwendet, wie Tabellen verbunden sind, usw. Die LIMIT-Klausel ist eine Art Post-Abfrage-Modifier ... jetzt, da wir wissen, was wir wollen, geben Sie nur die zuerst so viele. Das Zeilenfeld enthält also die Anzahl der möglichen Zeilen, die in der Abfrage vorhanden sind. Von dort würden OFFSET und LIMIT die spezifischen wählen, die Sie wünschen.

Ich denke, wenn Sie Ihre SELECT ohne EXPLAIN ausgeführt haben, erhalten Sie die Anzahl der Datensätze, die Sie wollten.

Answer 3

Ja, das Problem ist, dass Ihr Index nicht korrekt ist. Ich meine, Sie haben alle 3 Felder indiziert und Ihre Select-Abfrage prüft nur auf eins. Bei der MySQL-Indexierung unterscheiden sich 2 Zeilen separat von der 3-Zeilen-Indexierung.

Versuchen

CREATE TABLE IF NOT EXISTS `tbl_folder` (
    `id` int(11) NOT NULL AUTO_INCREMENT, 
    `owner_userid` int(11) NOT NULL, 
    `name` varchar(63) NOT NULL, 
    `description` text NOT NULL, 
    `visibility` tinyint(4) NOT NULL DEFAULT '2', 
    `num_items` int(11) NOT NULL DEFAULT '0', 
    `num_subscribers` int(11) NOT NULL DEFAULT '0', 
    PRIMARY KEY (`id`), 
    KEY `owner_userid` (`owner_userid`), 
    KEY `vis_index` (`visibility`), 
    KEY `vis_sub_item` (`num_subscribers`,`num_items`) 
) ENGINE=InnoDB