MySQL前缀索引导致的慢查询分析总结
更新时间：2013年05月19日 16:12:15 作者：
前缀索引，并不是一个万能药，他的确可以帮助我们对一个写过长的字段上建立索引。但也会导致排序（order by ，group by）查询上都是无法使用前缀索引的
前端时间跟一个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> 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定义，合理的规划自己的字段长度，字段类型都是首要的事情。
相关文章
MVCC是一种用于管理数据库并发访问的技术,它通过在数据库中存储数据的多个版本来避免读写冲突,从而提高了数据库的并发性能,这篇文章主要介绍了MySQL MVCC(多版本并发控制)实现的相关资料,需要的朋友可以参考下2026-06-06
这篇文章主要为大家详细介绍了Linux CentOS MySQL数据库的安装配置教程，具有一定的参考价值，感兴趣的小伙伴们可以参考一下2017-05-05
当 SQL Server 单表数据量突破千万级别,查询越来越慢几乎是必然会出现的问题,本文将结合生产实践为大家提供一套完整的调优流程,有需要的小伙伴可以了解下2026-08-08
这篇文章主要介绍了MySQL的加密解密的几种方式(小结)，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧2021-03-03
MariaDB是MySQL源代码的一个分支，主要由开源社区在维护，采用GPL授权许可。MariaDB 10.0和MySQL 5.6的不同之处有那些，MariaDB和Percona有什么不同呢？下面通过本文详细了解下吧2016-12-12
phpMyAdmin下将Excel中的数据导入MySql的图文方法
使用phpMyAdmin将Excel中的数据导入MySql，需要将execl导入到mysql数据库的朋友可以参考下。2010-08-08
文章介绍了MySQL中的gtid_purged变量,该变量用于记录已经从磁盘上被清除的二进制日志文件中的事务的GTID集合,它在服务器启动时初始化,本文介绍的非常详细感兴趣的朋友一起看看吧2025-12-12
在Linux环境下进行MySQL的安装可以使用不同的方式,但在本文中我们将关注一种特定的方式,即通过RPM包的方式进行安装,本文主要介绍了rpm -ivh方式安装mysql并修改数据存储位置的实现,感兴趣的可以了解一下2023-09-09
本篇文章对mysql数据类型进行了详细的介绍，需要的朋友参考下2013-05-05
这篇文章主要给大家介绍了关于Mysql中count带条件计数的相关资料,Mysql中count()函数的一般用法是统计字段非空的记录数,所以可以利用这个特点来进行条件统计,需要的朋友可以参考下2023-09-09
最新评论