Приветствую друзья!
Имеется вот такая табличка в сокращенном виде (mysql 5.7, 5Gb, 11 млн строк):
CREATE TABLE `docs` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`numb` INT(11) NULL DEFAULT NULL,
`is_delete` TINYINT(4) NOT NULL DEFAULT '0',
`is_draft` TINYINT(4) NOT NULL DEFAULT '0'
PRIMARY KEY (`id`, `is_draft`, `is_delete`),
UNIQUE INDEX `ux_numb` (`numb`, `is_draft`, `is_delete`)
)
/*!50100 PARTITION BY LIST (is_draft*10+is_delete)
(PARTITION main VALUES IN (0) ENGINE = MyISAM,
PARTITION drafts VALUES IN (10) ENGINE = MyISAM,
PARTITION dels VALUES IN (1) ENGINE = MyISAM,
PARTITION dels_drafts VALUES IN (11) ENGINE = MyISAM) */;
И есть к ней вот такой запрос:
SELECT
`id`,
`numb`
FROM `docs`
WHERE numb >= 38248393 AND numb <= 38248400
ORDER BY numb DESC
LIMIT 25
Этот запрос выполняется более 30 секунд. И я не могу понять почему, ведь выборка идет по уникальному ключу.
Если из данного запроса выкинуть из SELECT поле `id`, или убрать ORDER BY или во WHERE numb не диапазон а точное соответствие (например WHERE numb = 38248393) - то запрос выполняется за 0,00... секунды.
На быстро поставленной на соседнем сервере MariaDB на копии этой же базы запрос выполняется 0,016 секунды.
Явно mysql в таком сочетании условий делает fullscan зачем то. Explain не показывает ничего криминального:
"id" "select_type" "table" "partitions" "type" "possible_keys" "key" "key_len" "ref" "rows" "filtered" "Extra"
"1" "SIMPLE" "docs" "main,drafts,dels,dels_drafts" "range" "ux_numb" "ux_numb" "5" "7" "2,62" "Using index condition; Using where"
Это баг какой то или фича?
