MySQL索引优化的实际案例分析

更新时间：2015年05月08日 09:13:09 作者：罗龙九

这篇文章主要介绍了MySQL索引优化的一些实际案例,主要是用到Order by desc/asc limit M的方法,需要的朋友可以参考下

Order by desc/asc limit M是我在mysql sql优化中经常遇到的一种场景，其优化原理也非常的简单，就是利用索引的有序性，优化器沿着索引的顺序扫描，在扫描到符合条件的M行数据后，停止扫描；看起来非常的简单，但是我经常看到很多性能较差的sql没有利用这个优化规律，下面将结合一些实际的案例来分析说明：

案例一：

一条sql执行非常的慢，执行时间为：

root@test 02:00:44
 
SELECT * FROM test_order_desc WHERE END_TIME&gt;now() ORDER BY GMT_CREATE DESC,count_num DESC LIMIT 12, 12;
 
+---------+-----------+------------+------+---------------------+---------------------+-------------------
Data1.....................................................................................................
 
Data2.....................................................................................................
 
+---------+-----------+------------+------+---------------------+---------------------+-------------------
12 ROWS IN SET (0.49 sec)

执行计划如下：

root@test_db01:53:23
 
EXPLAIN SELECT * FROM test_order_desc WHERE END_TIME &gt; now()
 ORDER BY GMT_CREATE DESC,count_num DESC LIMIT 12, 12;
 
+----+-------------+----------+-------+-----------------+-----------------+---------+------+--------+-----
 
| id | select_type | TABLE  | TYPE | possible_keys  | KEY  | key_len | REF | ROWS  | Extra   |
 
+----+-------------+----------+-------+-----------------+-----------------+---------+------+--------+-----
 
| 1 | SIMPLE   | test_order_desc | range | ind_hot_endtime | ind_hot_endtime | 9    | NULL | 113549 | USING WHERE; USING filesort |
 
+----+-------------+----------+-------+-----------------+-----------------+---------+------+--------+-----

Ind_hot_endtime索引为：

root@test_db01:52:45:SHOW INDEX FROM test_order_desc;
 
Ind_hot_endtime(end_time,count_num)

在注意到sql中满足过滤条件end_time>now()的有113549行，在加上剩余的条件中含有order by，这样会造成排序的结果集非常的大，执行非常的耗费资源；于是分析sql，在sql中包括了order by desc limit这样的排序条件后，新增适当的索引满足排序的条件，同时由于有limit的限制结果集，当扫描到满足条件的行数后退出查询，那么我们来看看优化效果：

添加索引：

root@test 02:01:06:ALTER TABLE test_order_desc ADD INDEX ind_gmt_create(gmt_create,count_num);
 
Query OK, 211945 ROWS affected (6.71 sec)
 
Records: 211945 Duplicates: 0 Warnings: 0

再次执行sql，观察其执行时间：

root@test 02:01:35:
 
SELECT * FROM test_order_desc WHERE END_TIME &gt; now()  ORDER BY GMT_CREATE DESC,count_num DESC LIMIT 12, 12;
 
+---------+-----------+------------+------+---------------------+---------------------+
col2...................................................................................
 
+---------+-----------+------------+------+---------------------+---------------------+
 
Data1..................................................................................
 
Data2..................................................................................
 
+---------+-----------+------------+------+---------------------+---------------------+
 
12 ROWS IN SET (0.00 sec)

可以看到执行时间已经降到了毫秒以下,查看其执行计划：

root@test 02:01:42:
 
EXPLAIN SELECT * FROM test_order_desc WHERE END_TIME &gt; now() ORDER BY GMT_CREATE DESC,count_num DESC LIMIT 12, 12;
 
+----+-------------+----------+-------+-----------------+----------------+---------+------+------+-------------+
 
| id | select_type | TABLE  | TYPE | possible_keys  | KEY | key_len | REF | ROWS | Extra |
 
+----+-------------+----------+-------+-----------------+----------------+---------+------+------+--------
 
| 1 | SIMPLE   | test_order_desc | INDEX | ind_hot_endtime | ind_gmt_create | 14   | NULL | 48 | USING WHERE |

可以看到优化器已经选择了ind_gmt_create索引扫描，这样的话就避免了对结果集进行排序的过程，同时优化器预估扫描14行数据就会得到满足查询条件的数据（END_TIME > now()），执行计划非常的理想。

root@127.0.0.1 : test_db 16:05:15:
EXPLAIN SELECT b.*,a.*,k.*  FROM instance b LEFT OUTER JOIN image a ON b.image_id=a.image_id LEFT OUTER JOIN key_pair k ON b.key_pair_id=k.key_pair_id LEFT OUTER JOIN region_alias r_a ON r_a.region_no=b.region_no WHERE b.STATUS IN (1,8) AND  b.user_id = 21 AND r_a.big_region_no='regeion_xx' ORDER BY b.instance_no ASC LIMIT 37300,50;

案例二：

root@127.0.0.1 : test_db 16:05:15:
EXPLAIN SELECT b.*,a.*,k.*  FROM instance b LEFT OUTER JOIN image a ON b.image_id=a.image_id LEFT OUTER JOIN key_pair k ON b.key_pair_id=k.key_pair_id LEFT OUTER JOIN region_alias r_a ON r_a.region_no=b.region_no WHERE b.STATUS IN (1,8) AND  b.user_id = 21 AND r_a.big_region_no='regeion_xx' ORDER BY b.instance_no ASC LIMIT 37300,50;

20155891104431.jpg (749×177)

B表的idx_uid_stat_inid的索引列包括了（user_id，status，instance_no）：

20155891213308.jpg (668×123)

我们从执行计划上分析来看，表的连接顺序为：b—>r_a—>a—>k，可以看到执行计划的第一行中需要扫描49212行的数据,同时由于status采用的是in的方式，instance_no即使在索引中也用不上，这样就导致了排序使用到了临时表,这也是导致sql执行慢的原因。我们看到sql中的最后一个排序为order by b.instance_no asc limit 37300,50，这里我们好像可以看到优化的曙光，调整数据库的索引以满足B表的排序需求：

root@127.0.0.1 : test_db 16:05:04 ALTER TABLE instance ADD INDEX ind_user_id(user_id,instance_no);
Query OK, 0 ROWS affected (0.56 sec)

调整索引后查看执行计划：

root@127.0.0.1 : test_db 16:09:42
EXPLAIN SELECT b.*,a.*,k.*  FROM instance b LEFT OUTER JOIN image a ON b.image_id=a.image_id LEFT OUTER JOIN key_pair k ON b.key_pair_id=k.key_pair_id LEFT OUTER JOIN region_alias r_a ON r_a.region_no=b.region_no WHERE b.STATUS IN (1,8) AND  b.user_id = 21 AND r_a.big_region_no='regeion_xx' ORDER BY b.instance_no ASC LIMIT 37300,50;

20155891233937.jpg (741×180)

我们加上force index强制走我们新加的索引：

root@127.0.0.1 : test_db 16:10:24
EXPLAIN SELECT b.*,a.*,k.*  FROM instance b force INDEX (ind_user_id) LEFT OUTER JOIN image a ON b.image_id=a.image_id LEFT OUTER JOIN key_pair k ON b.key_pair_id=k.key_pair_id LEFT OUTER JOIN region_alias r_a ON r_a.region_no=b.region_no WHERE b.STATUS IN (1,8) AND  b.user_id = 21 AND r_a.big_region_no='regeion_xx' ORDER BY b.instance_no ASC LIMIT 37300,50;

20155891300180.jpg (726×164)

可以看到在加上提示符后，使用到了我们新加的索引，扫描的行数为54580行，执行时间：

root@127.0.0.1 : test_db 16:10:30
SELECT b.*,a.*,k.*  FROM instance b force INDEX (ind_user_id) LEFT OUTER JOIN image a ON b.image_id=a.image_id LEFT OUTER JOIN key_pair k ON b.key_pair_id=k.key_pair_id LEFT OUTER JOIN region_alias r_a ON r_a.region_no=b.region_no WHERE b.STATUS IN (1,8) AND  b.user_id = 21 AND r_a.big_region_no='regeion_xx' ORDER BY b.instance_no ASC LIMIT 37300,50;
(0.49 sec)

原始的执行时间：

root@127.0.0.1 : test_db 16:10:51:
SELECT b.*,a.*,k.*  FROM instance b  LEFT OUTER JOIN image a ON b.image_id=a.image_id LEFT OUTER JOIN key_pair k ON b.key_pair_id=k.key_pair_id LEFT OUTER JOIN region_alias r_a ON r_a.region_no=b.region_no WHERE b.STATUS IN (1,8) AND  b.user_id = 21 AND r_a.big_region_no='regeion_xx' ORDER BY b.instance_no ASC LIMIT 37300,50;
(1.28 sec)

总结：
Order by desc/asc limit的优化技术有时候在你无法建立很好索引的时候，往往会得到意想不到的优化效果，但有时候有一定的局限性，优化器可能不会按照你既定的索引路径扫描，优化器需要考虑到查询列的过滤性以及limit的长度，当查询列的选择性非常高的时候，使用sort的成本是不高的，当查询列的选择性很低的时候，那么使用order by +limit的技术是很有效的。

您可能感兴趣的文章:

MySQL

LEFT JOIN条件在on后面和在where后面的区别及说明
这篇文章主要介绍了LEFT JOIN条件在on后面和在where后面的区别及说明,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教
2023-09-09
MySQL如何开启用户远程登录权限
这篇文章主要介绍了MySQL如何开启用户远程登录权限问题，具有很好的参考价值，希望对大家有所帮助。如有错误或未考虑完全的地方，望不吝赐教
2023-04-04
MySql批量插入优化Sql执行效率实例详解
这篇文章主要介绍了MySql批量插入优化Sql执行效率实例详解的相关资料,需要的朋友可以参考下
2017-04-04
MySQL插入emoji表情失败问题的解决方法
emoji表情在我们日常开发中经常会遇到，但是最近在mysql中插入emoji表情遇到了问题，通过查找相关的资料终于解决了，所以将这次解决的过程分享出来，这篇文章主要就给大家介绍了MySQL插入emoji表情失败问题的解决方法，需要的朋友可以参考。
2017-05-05
Mysql中的事务是什么如何使用
事务是逻辑上的一组操作，组成这组操作的各个单元，要不全都成功要不全都失败，这个特性就是事务，下面为大家介绍下Mysql中的事务的具体使用
2013-12-12
聊一聊MyISAM和InnoDB的区别
这篇文章主要介绍了聊一聊MyISAM和InnoDB的区别，具有很好的参考价值，希望对大家有所帮助。一起跟随小编过来看看吧
2020-08-08
MySql 5.7.20安装及data和my.ini文件的配置
本文通过图文并茂的形式给大家介绍了MySql 5.7.20安装及data和my.ini文件的配置方法，本文给大家介绍的非常详细，需要的朋友参考下吧
2017-11-11
Mysql数据库如何使用DELETE语句从数据库表中删除数据(数据库数据删除)
DELETE语句是SQL中的一个重要功能,允许用户根据特定条件删除表中的数据行,在本文中,我们探讨了如何使用DELETE语句从数据库表中删除数据,感兴趣的朋友跟随小编一起看看吧
2024-08-08
教你3个步骤为Mysql添加只读账号
只要公司有数据团队的那免不了让这帮家伙把全公司的数据库数据都摸一遍,但是要是直接把root用户给了他们有点危险,于是只能给设权限,这篇文章主要给大家介绍了关于如何通过3个步骤为Mysql添加只读账号的相关资料,需要的朋友可以参考下
2023-12-12
使用mysql workbench自动生成ER图的实现步骤
MySQL Workbench是一款专为MySQL设计的ER/数据库建模工具,它是著名的数据库设计工具DBDesigne4的继任者,可以通过MySQL Workbench设计和创建新的数据库图示,本文给大家介绍了使用mysql workbench自动生成ER图的实现步骤,需要的朋友可以参考下
2024-06-06

MySQL索引优化的实际案例分析

相关文章

最新评论

大家感兴趣的内容

最近更新的内容

常用在线小工具