视频1 视频21 视频41 视频61 视频文章1 视频文章21 视频文章41 视频文章61 推荐1 推荐3 推荐5 推荐7 推荐9 推荐11 推荐13 推荐15 推荐17 推荐19 推荐21 推荐23 推荐25 推荐27 推荐29 推荐31 推荐33 推荐35 推荐37 推荐39 推荐41 推荐43 推荐45 推荐47 推荐49 关键词1 关键词101 关键词201 关键词301 关键词401 关键词501 关键词601 关键词701 关键词801 关键词901 关键词1001 关键词1101 关键词1201 关键词1301 关键词1401 关键词1501 关键词1601 关键词1701 关键词1801 关键词1901 视频扩展1 视频扩展6 视频扩展11 视频扩展16 文章1 文章201 文章401 文章601 文章801 文章1001 资讯1 资讯501 资讯1001 资讯1501 标签1 标签501 标签1001 关键词1 关键词501 关键词1001 关键词1501 专题2001
MySQL前缀索引导致的慢查询分析总结
2020-11-09 21:09:04 责编:小采
文档


前端时间跟一个DB相关的项目,alanc反馈有一个查询,使用索引比不使用索引慢很多倍,有点毁三观。所以跟进了一下,用explain,看了看2个查询不同的结果。

不用索引的查询的时候结果如下,实际查询中速度比较块。
代码如下:
mysql> explain select * from rosterusers limit 10000,3 ;

+----+-------------+-------------+------+---------------+------+---------+------+---------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------------+------+---------------+------+---------+------+---------+-------+
| 1 | SIMPLE | rosterusers | ALL | NULL | NULL | NULL | NULL | 2010066 | |
+----+-------------+-------------+------+---------------+------+---------+------+---------+-------+

而使用索引order by的查询结果如下,速度反而慢的惊人。
mysql> explain select * from rosterusers order by username limit 10000,3 ;
+----+-------------+-------------+------+---------------+------+---------+------+---------+----------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------------+------+---------------+------+---------+------+---------+----------------+
| 1 | SIMPLE | rosterusers | ALL | NULL | NULL | NULL | NULL | 2010087 | Using filesort |
+----+-------------+-------------+------+---------------+------+---------+------+---------+----------------+

区别在于,使用索引查询的Extra变成了,Using filesort。居然用了使用外部文件进行排序。这个当然慢了。

但数据表上在username,的确是有索引的。怎么会反而要Using filesort?
看了一下数据表定义。是一个开源聊天服务器ejabberd的一张表。初看以为主键i_rosteru_user_jid是username,和jid的联合索引,那么使用order by username时应该是可以使用到索引才对呀?
代码如下:
CREATE TABLE `rosterusers` (
`username` varchar(250) NOT NULL,
`jid` varchar(250) NOT NULL,
UNIQUE KEY `i_rosteru_user_jid` (`username`(75),`jid`(75)),
KEY `i_rosteru_jid` (`jid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

仔细检查突然发现其主键定义,不是定义的完整的主键名称,而跟了一个75的长度描述,稍稍一愣,原来用的是前缀索引,而不是整个字段都是索引。(我的记忆里面InnoDB还不支持这玩意,估计是4.0后什么版本加入的),前缀索引就是将数据字段中前面N个字节作为索引的一种方式。

发现了这个问题后,我们开始怀疑慢查询和这个索引有关,前缀索引的主要用途在于有时字段过程,而MySQL支持的很多索引长度是有的。
首先不带order by 的limit 这种查询,本质可能还是和主键相关的,因为MySQL 的INNODB的操作实际都是依靠主键的(即使你没有建立,系统也会有一个默认的),而limit这种查询,使用主键是可以加快速度,(explain返回的rows 应该是一个参考值),虽然我没有看见什么文档明确的说明过这个问题,但从不带order by 的limit 查询的返回结果基本可以证明这点。

但当我们使用order by username的时候,由于希望使用的是username的排序,而不是username(75)的排序,但实际索引是前缀索引,不是完整字段的索引。所以反而导致了order by的时候完全无法利用索引了。(我在SQL语句里面增加强制使用索引i_rosteru_user_jid也不起作用)。而其实使用中,表中的字段username 连75个都用不到,何况定义的250的长度。完全是自己折腾导致的麻烦。由于这是其他产品的表格,我们无法更改,暂时只能先将就用不不带排序的查询讲究。

总结:
•前缀索引,并不是一个万能药,他的确可以帮助我们对一个写过长的字段上建立索引。但也会导致排序(order by ,group by)查询上都是无法使用前缀索引的。
•任何时候,对于DB Schema定义,合理的规划自己的字段长度,字段类型都是首要的事情。

您可能感兴趣的文章:

  • Mysql慢查询优化方法及优化原则
  • Mysql查询很慢卡在sending data的原因及解决思路讲解
  • 深入分析MySQL Sending data查询慢问题
  • mysql in语句子查询效率慢的优化技巧示例
  • MySQL数据库中把int转化varchar引发的慢查询
  • mysql服务器查询慢原因分析与解决方法小结
  • mysql查询慢的原因和解决方案
  • 下载本文
    显示全文
    专题