Фильтр объяснения mariadb = 100, хотя выбран правильный индекс

Question

Я пытаюсь выяснить, почему я получаю ужасную производительность по очень простому запросу:

объяснение счетчика выбора (*) от call_details_raw, где PNBLSTimeOn между '2019-03-1002:15:00 'и' 2019-03-10 02: 20: 00 '

+------+-------------+------------------+-------+---------------+-------------+---------+------+---------+----------+--------------------------+
| id   | select_type | table            | type  | possible_keys | key         | key_len | ref  | rows    | filtered | Extra                    |
+------+-------------+------------------+-------+---------------+-------------+---------+------+---------+----------+--------------------------+
|    1 | SIMPLE      | call_details_raw | index | PNBLSTimeOn   | PNBLSTimeOn | 5       | NULL | 7566362 |   100.00 | Using where; Using index |
+------+-------------+------------------+-------+---------------+-------------+---------+------+---------+----------+--------------------------+

mysql занимает очень много времени, чтобы сказать мне, что результат равен 0:

+----------+
| count(*) |
+----------+
|        0 |
+----------+
1 row in set (4.68 sec)

Он говорит, что использует правильный индекс, но filter = 100, что означает, что он все равно анализирует каждую строку в таблице.

Вот полное определение таблицы, если это поможет:

CREATE TABLE `call_details_raw` (
  `call_id` int(11) NOT NULL AUTO_INCREMENT,
  `PNBLSPrimaryCSN` char(16) COLLATE utf8_bin DEFAULT NULL,
  `PNBLSBillingAccount` char(16) COLLATE utf8_bin DEFAULT NULL,
  `PNBLSMainAccount` char(16) COLLATE utf8_bin DEFAULT NULL,
  `PNBLSXferAccount` char(16) COLLATE utf8_bin DEFAULT NULL,
  `PNBLSTimeOn` timestamp NULL DEFAULT NULL,
  `PNBLSTimeOff` timestamp NULL DEFAULT NULL,
  `PNBLSNumberDialed` char(20) COLLATE utf8_bin DEFAULT NULL,
  `PNBLSANI` char(20) COLLATE utf8_bin DEFAULT NULL,
  `PNBLSTotalTime` int(11) DEFAULT NULL,
  `PNBLSRingTime` decimal(11,1) DEFAULT NULL,
  `PNBLSHoldTime` int(11) DEFAULT NULL,
  `PNBLSQueueTime` int(11) DEFAULT NULL,
  `PNBLSInboundTime` int(11) DEFAULT NULL,
  `PNBLSInboundCall` int(11) DEFAULT NULL,
  `PNBLSOutboundTime` int(11) DEFAULT NULL,
  `PNBLSOutboundCall` int(11) DEFAULT NULL,
  `PNBLSCheckinTime` int(11) DEFAULT NULL,
  `PNBLSCheckinCall` int(11) DEFAULT NULL,
  `PNBLSVMTime` int(11) DEFAULT NULL,
  `PNBLSVMCall` int(11) DEFAULT NULL,
  `PNBLSPagerTime` int(11) DEFAULT NULL,
  `PNBLSPagercall` int(11) DEFAULT NULL,
  `PNBLSConfTime` int(11) DEFAULT NULL,
  `PNBLSConfCall` int(11) DEFAULT NULL,
  `PNBLSConfParties` int(11) DEFAULT NULL,
  `PNBLSConfSetupTime` int(11) DEFAULT NULL,
  `PNBLSAppDialouts` int(11) DEFAULT NULL,
  `PNBLSAlphaPages` int(11) DEFAULT NULL,
  `PNBLSFaxes` int(11) DEFAULT NULL,
  `PNBLSEmails` int(11) DEFAULT NULL,
  `PNBLSMsgsSaved` int(11) DEFAULT NULL,
  `PNBLSNoMsgs` int(11) DEFAULT NULL,
  `PNBLSWorkTime` int(11) DEFAULT NULL,
  `PNBLSMLTime` int(11) DEFAULT NULL,
  `PNBLSLiveRecTime` int(11) DEFAULT NULL,
  `PNBLSLiveRecCall` int(11) DEFAULT NULL,
  `PNBLSSATime` int(11) DEFAULT NULL,
  `PNBLSInEmails` int(11) DEFAULT NULL,
  `PNBLSConfSetups` int(11) DEFAULT NULL,
  `PNBLSAgentConfTime` int(11) DEFAULT NULL,
  `PNBLSParkTime` int(11) DEFAULT NULL,
  `PNBLSFlashOverTrunk` int(11) DEFAULT NULL,
  `PNBLSAutoDigCalls` int(11) DEFAULT NULL,
  `PNBLSAutoDigTime` int(11) DEFAULT NULL,
  `PNBLSMsgTime` int(11) DEFAULT NULL,
  `PNBLSMsgEditTime` int(11) DEFAULT NULL,
  `PNBLSMsgTimeSusp` int(11) DEFAULT NULL,
  `PNBLSMsgEditTimeSusp` int(11) DEFAULT NULL,
  `PNBLSWorkTimeSusp` int(11) DEFAULT NULL,
  `PNBLSMsgListSusp` int(11) DEFAULT NULL,
  `PNBLSSATimeSusp` int(11) DEFAULT NULL,
  `PNBLSPreAnnounceCall` int(11) DEFAULT NULL,
  `PNBLSPreAnnounceTime` int(11) DEFAULT NULL,
  `PNBLSAbandonedCall` int(11) DEFAULT NULL,
  `PNBLSWrapTime` int(11) DEFAULT NULL,
  `PNBLSLastAgent` char(16) COLLATE utf8_bin DEFAULT NULL,
  `PNBLSLastAgentName` varchar(30) COLLATE utf8_bin DEFAULT NULL,
  `PNBLSLocates` int(11) DEFAULT NULL,
  `PNBLSLocateTime` int(11) DEFAULT NULL,
  `PNBLSSMSIn` int(11) DEFAULT NULL,
  `PNBLSSMSOut` int(11) DEFAULT NULL,
  `PNBLSPF2Fax` int(11) DEFAULT NULL,
  `PNBLSPF2FaxTime` int(11) DEFAULT NULL,
  `PNBLSPF2FaxPages` int(11) DEFAULT NULL,
  `PNBLSPPSPage` int(11) DEFAULT NULL,
  `PNBLSPPSPageTime` int(11) DEFAULT NULL,
  `PNBLSQueueDrop` int(11) DEFAULT NULL,
  `PNBLSPreAnnDrop` int(11) DEFAULT NULL,
  `PNBLSMsgInsAPI` int(11) DEFAULT NULL,
  `PNBLSOrderNum` char(16) COLLATE utf8_bin DEFAULT NULL,
  `PNBLSSecMsgIn` int(11) DEFAULT NULL,
  `PNBLSSecMsgOut` int(11) DEFAULT NULL,
  `PNBLSSecMsgRead` int(11) DEFAULT NULL,
  PRIMARY KEY (`call_id`),
  KEY `PNBLSTimeOn` (`PNBLSTimeOn`),
  KEY `PNBLSTimeOff` (`PNBLSTimeOff`),
  KEY `PNBLSInboundCall` (`PNBLSInboundCall`),
  KEY `PNBLSLastAgent` (`PNBLSLastAgent`)
) ENGINE=InnoDB AUTO_INCREMENT=7994796 DEFAULT CHARSET=utf8 COLLATE=utf8_bin

select @@version;
10.1.30-MariaDB

Answer 1

Я не знаю, актуальны ли они;они приходят из журналов изменений:

----- 2017-05-23 MariaDB 10.2.6 - - -----

Ошибка # 23046302 СЧЕТ (*) НАМНОГО МЕНЬШЕON 5.7 THAN 5.6

----- 2017-04-10 5.7.18 Общая доступность - Исправлены ошибки - InnoDB -----

ВЫБРАННАЯ COUNT (*) производительность сниженав некоторых случаях из-за модификации, введенной в MySQL 5.7.2, которая заставляла InnoDB подсчитывать строки путем обхода кластеризованного индекса вместо меньшего вторичного индекса.Модификация была отменена.(Ошибка # 23046302, Ошибка # 80580)

----- 2017-04-10 5.7.18 Общая доступность - Исправлены ошибки - -----

ОБЪЯСНИТЬ ВЫБРАТЬ СЧЕТЧИК(*) FROM tbl_name может неправильно сообщать о оптимизированном дополнительном значении таблиц Select из-за модификации, введенной в MySQL 5.7.2, которая заставляет InnoDB подсчитывать строки путем обхода кластеризованного индекса вместо меньшего вторичного индекса.Значение Extra теперь отображает количество строк.(Ошибка № 24337385, Ошибка № 82313)

Answer 2

Debian 9 плюс текущее значение по умолчанию 10.1.38-MariaDB-0 + deb9u1 исправили проблему.

Тот же хостинг AWS, то же распределение ресурсов процессора, памяти и iops для хранения.

Можетбыть ошибкой в ​​10.1.30, которая исправлена ​​в 10.1.38, но в равной степени возможно, что есть проблема конфигурации в том, как она распространяется с xampp.

Я не склонен копать дальше, но в случае, если кто-то еще работаетВ некоторых странных проблемах с производительностью MariaDB в Windows они могли бы подумать о переходе на Linux, чтобы посмотреть, решит ли это их проблему.