Question

我试图弄清楚为什么在一个非常简单的查询中却获得了糟糕的性能：

从call_details_raw中解释选择计数（*），其中PNBLSTimeOn在'2019-03-10 02: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

Debian 9加上当前默认的10.1.38-MariaDB-0 + deb9u1解决了该问题。

相同的AWS托管，相同的CPU，内存和存储iops资源分配。

可能是10.1.30中的一个错误，该错误已在10.1.38中修复，但同样有可能在xampp的分发方式中存在配置问题。

我不愿进一步探讨，但是如果其他人在Windows上的MariaDB中遇到一些奇怪的性能问题，他们可能会考虑切换到Linux，看看它是否可以解决问题。

Answer 2

我不知道这些是否相关；它们来自变更日志：

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

错误＃23046302 COUNT（*）比5.6慢5.7

----- 2017-04-10 5.7.18常规可用性-修复了错误-InnoDB -----

在某些情况下，SELECT COUNT（*）性能下降，这是由于MySQL 5.7.2中引入的修改导致InnoDB通过遍历聚集索引而不是较小的辅助索引来对行进行计数。修改已还原。（错误＃23046302，错误＃80580）

----- 2017-04-10 5.7.18常规可用性-修复了错误------

从tbl_name扩展EXPLAIN SELECT COUNT（*）可能会错误地报告由于MySQL 5.7.2中引入的修改导致InnoDB通过遍历聚集索引而不是较小的辅助索引来对行进行计数而导致优化后的Select表的额外值。现在，“额外”值将显示“计数行”。（错误＃24337385，错误＃82313）

mariadb解释filter = 100即使选择了正确的索引

2 个答案: