个人中心
文章发布
退出
作者热门文章
- ubuntu12.04环境下使用kvm ioctl接口实现最简单的虚拟机
- Ubuntu 通过无线网络安装Ubuntu Server启动系统后连接无线网络的方法
- 在Ubuntu上搭建网桥的方法
- ubuntu 虚拟机上网方式及相关配置详解
25
4
CFSDN坚持开源创造价值，我们致力于搭建一个资源共享平台，让每一个IT人在这里找到属于你的精彩世界.
这篇CFSDN的博客文章MySQL索引优化的实际案例分析由作者收集整理，如果你对这篇文章有兴趣，记得点赞哟.
Order by desc/asc limit M是我在mysql sql优化中经常遇到的一种场景，其优化原理也非常的简单，就是利用索引的有序性，优化器沿着索引的顺序扫描，在扫描到符合条件的M行数据后，停止扫描；看起来非常的简单，但是我经常看到很多性能较差的sql没有利用这个优化规律，下面将结合一些实际的案例来分析说明:
案例一:
一条sql执行非常的慢，执行时间为:
|
1
2
3
4
5
6
7
8
9
10
11
|
root@
test
02:00:44
SELECT * FROM test_order_desc WHERE END_TIME>now() ORDER BY GMT_CREATE DESC,count_num DESC LIMIT 12, 12;
+---------+-----------+------------+------+---------------------+---------------------+-------------------
Data1.....................................................................................................
Data2.....................................................................................................
+---------+-----------+------------+------+---------------------+---------------------+-------------------
12 ROWS IN SET (0.49 sec)
|
执行计划如下:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
root@test_db01:53:23
EXPLAIN SELECT * FROM test_order_desc WHERE END_TIME > 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索引为:
|
1
2
3
|
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的限制结果集，当扫描到满足条件的行数后退出查询，那么我们来看看优化效果:
添加索引:
|
1
2
3
4
5
|
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，观察其执行时间:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
root@
test
02:01:35:
SELECT * FROM test_order_desc WHERE END_TIME > now() ORDER BY GMT_CREATE DESC,count_num DESC LIMIT 12, 12;
+---------+-----------+------------+------+---------------------+---------------------+
col2...................................................................................
+---------+-----------+------------+------+---------------------+---------------------+
Data1..................................................................................
Data2..................................................................................
+---------+-----------+------------+------+---------------------+---------------------+
12 ROWS IN SET (0.00 sec)
|
可以看到执行时间已经降到了毫秒以下,查看其执行计划:
|
1
2
3
4
5
6
7
8
9
10
11
|
root@
test
02:01:42:
EXPLAIN SELECT * FROM test_order_desc WHERE END_TIME > 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()），执行计划非常的理想.
。
|
1
2
|
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;
|
案例二:
|
1
2
|
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;
|
B表的idx_uid_stat_inid的索引列包括了（user_id，status，instance_no）:
我们从执行计划上分析来看，表的连接顺序为：b—>r_a—>a—>k，可以看到执行计划的第一行中需要扫描49212行的数据,同时由于status采用的是in的方式，instance_no即使在索引中也用不上，这样就导致了排序使用到了临时表,这也是导致sql执行慢的原因。我们看到sql中的最后一个排序为order by b.instance_no asc limit 37300,50，这里我们好像可以看到优化的曙光，调整数据库的索引以满足B表的排序需求:
|
1
2
|
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)
|
调整索引后查看执行计划:
|
1
2
|
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;
|
我们加上force index强制走我们新加的索引:
|
1
2
|
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;
|
可以看到在加上提示符后，使用到了我们新加的索引，扫描的行数为54580行，执行时间:
|
1
2
3
|
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)
|
原始的执行时间:
|
1
2
3
|
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索引优化的实际案例分析的文章就讲到这里了,如果你想了解更多关于MySQL索引优化的实际案例分析的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。
25
4
0
比较代码: const char x = 'a'; std::cout > (0C310B0h) 00C3100B add esp,4 和 const i
您好，我正在使用 Matlab 优化求解器，但程序有问题。我收到此消息 fmincon 已停止，因为目标函数值小于目标函数限制的默认值，并且约束满足在约束容差的默认值范围内。我也收到以下消息。警告:矩
处理Visual Studio optimizations的问题为我节省了大量启动和使用它的时间 当我必须进行 J2EE 开发时，我很难回到 Eclipse。因此，我还想知道人们是否有任何提示或技巧可
情况如下:在我的 Excel 工作表中，有一列包含 1-name 形式的条目。考虑到数字也可以是两位数，我想删除这些数字。这本身不是问题，我让它工作了，只是性能太糟糕了。现在我的程序每个单元格输入大约
这样做有什么区别吗: $(".topHorzNavLink").click(function() { var theHoverContainer = $("#hoverContainer");
这个问题已经有答案了: 已关闭11 年前。 Possible Duplicate: What is the cost of '$(this)'? 我经常在一些开发人员代码中看到$(this)引用同一个
我刚刚结束了一个大型开发项目。我们的时间紧迫，因此很多优化被“推迟”。既然我们已经达到了最后期限，我们将回去尝试优化事情。 我的问题是:优化 jQuery 网站时您要寻找的最重要的东西是什么。或者，我
所以我一直在用 JavaScript 编写游戏(不是网络游戏，而是使用 JavaScript 恰好是脚本语言的游戏引擎)。不幸的是，游戏引擎的 JavaScript 引擎是 SpiderMonkey
这是我在正在构建的页面中使用的 SQL 查询。它目前运行大约 8 秒并返回 12000 条记录，这是正确的，但我想知道您是否可以就如何使其更快提出可能的建议？ SELECT DISTINCT Adve
如何优化这个？ SELECT e.attr_id, e.sku, a.value FROM product_attr AS e, product_attr_text AS a WHERE e.attr
我正在使用这样的结构来测试是否按下了所需的键: def eventFilter(self, tableView, event): if event.type() == QtCore.QEven
我正在使用 JavaScript 从给定的球员列表中计算出羽毛球 double 比赛的所有组合。每个玩家都与其他人组队。 EG。如果我有以下球员a、b、c、d。它们的组合可以是: a & b V c
我似乎无法弄清楚如何让这个 JS 工作。 scroll function 起作用但不能隐藏。还有没有办法用更少的代码行来做到这一点？我希望 .down-arrow 在 50px 之后 fade out
我的问题是关于用于生产的高级优化级联样式表 (CSS) 文件。 多么最新和最完整(准备在实时元素中使用)的 css 优化器/最小化器，它们不仅提供删除空格和换行符，还提供高级功能，如删除过多的属性、合
我读过这个: 浏览器检索在 中请求的所有资源开始呈现 之前的 HTML 部分.如果您将请求放在 中section 而不是，那么页面呈现和下载资源可以并行发生。您应该从 移动尽可能多的资源请求。
我正在处理一些现有的 C++ 代码，这些代码看起来写得不好，而且调用频率很高。我想知道我是否应该花时间更改它，或者编译器是否已经在优化问题。 我正在使用 Visual Studio 2008。 这是一
我正在尝试使用 OpenGL 渲染 3 个四边形(1 个背景图，2 个 Sprite )。我有以下代码: void GLRenderer::onDrawObjects(long p_dt) {
我确实有以下声明: isEnabled = false; if(foo(arg) && isEnabled) { .... } public boolean foo(arg) { some re
(一)深入浅出理解索引结构 实际上，您可以把索引理解为一种特殊的目录。微软的SQL SERVER提供了两种索引：聚集索引(clustered index，也称聚类索引、簇集索引)和非聚集索引(no
一、写在前面 css的优化方案，之前没有提及，所以接下来进行总结一下。 二、具体优化方案 2.1、加载性能 1、css压缩：将写好的css进行打包，可以减少很多的体积。 2、css单一样式：在需要下边
我是一名优秀的程序员,十分优秀！