该表约有20k行,创建代码如下:
CREATE TABLE `inventory` (
`ID` int(11) NOT NULL AUTO_INCREMENT,
`TID` int(11) DEFAULT NULL,
`RID` int(11) DEFAULT NULL,
`CID` int(11) DEFAULT NULL,
`value` text COLLATE utf8_unicode_ci,
PRIMARY KEY (`ID`),
KEY `index_TID_CID_value` (`TID`,`CID`,`value`(25))
);
这是explain查询的结果
mysql> explain select rowID from inventory where TID=4 and CID=28 and value=3290843588097;
+----+-------------+------------+------+------------------------+-----------------------+---------+-------------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------+------+------------------------+-----------------------+---------+-------------+------+-------------+
| 1 | SIMPLE | inventory | ref | index_TID_CID_value | index_TID_CID_value | 10 | const,const | 9181 | Using where |
+----+-------------+------------+------+------------------------+-----------------------+---------+-------------+------+-------------+
1 row in set (0.00 sec)
tid=4和cid=28的组合在表中大约有13k行。
我的问题是:
为什么解释结果告诉我大约9k行将被检查以得到最终结果?
为什么是专栏 ref
仅显示 const,const
由于多列索引中包含3列,因此不应 ref
是 const,const,const
?
2016年10月7日更新
查询:
select rowID from inventory where TID=4 and CID=28 and value=3290843588097;
我跑了大约10次,取了最后5次的时间(他们是一样的)
无索引-0.02秒
索引(tid、cid)-0.03秒
索引(tid、cid、值)-0.00秒
同样的解释查询今天看起来不一样,怎么??请注意,密钥len已更改为 88
裁判改成了 const,const,const
要检查的行也减少到 2
.
mysql> explain select rowID from inventory where TID=4 and CID=28 and value='3290843588097';
+----+-------------+-----------+------+----------------------+---------------------+---------+-------------------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-----------+------+----------------------+---------------------+---------+-------------------+------+-------------+
| 1 | SIMPLE | inventory | ref | index_TID_CID_value | index_TID_CID_value | 88 | const,const,const | 2 | Using where |
+----+-------------+-----------+------+----------------------+---------------------+---------+-------------------+------+-------------+
1 row in set (0.04 sec)
1条答案
按热度按时间hivapdat1#
明确回答你的问题。
explain计划提供了9k行查询,因为引擎需要搜索索引树来找到符合where子句条件的行id。索引将生成索引列值的每个可能组合到与该组合相关联的rowid列表的Map。实际上,引擎正在搜索这些组合以找到正确的组合;这是通过扫描组合来完成的,因此是~9k量。
由于where子句条件涉及所有三个索引列,因此引擎通过利用前两列的索引来优化搜索,然后短路第三列并获得该组合的所有rowid结果。
在您的特定用例中,我假设您希望优化搜索性能。我建议您只在tid和cid上创建一个索引(而不是value)。原因是,在~20k条记录中,当前只有2个组合的值。这意味着使用一个只有两列的索引,引擎在搜索所有三个值时,几乎可以立即删除一半的记录(这都是假设此索引将应用于具有更大数据集的表。)由于您的度量基于更小的数据集,因此您可能看不到使用索引和不使用索引之间性能差异的数量级。