MySQL Index--关联条件列索引缺失导致执行计划性能不佳
某系统反馈慢SQL影响生产,查看SLOW LOG发现下面慢SQL:
SELECT COUNT(DISTINCT m.batch_no)
FROM ob_relation r
INNER JOIN ob_batch_d d
ON r.sub_order_no = d.outbound_no
INNER JOIN ob_batch_m m
ON d.batch_no = m.batch_no
WHERE r.production_mode =1
AND r.yn=0
AND r.outbound_no ='xxxx2156'
AND d.yn=0
AND m.yn=0
AND m.SEND_FLAG=0
AND m.batch_no!='xxx00025984';
设计表上索引情况如下:
表ob_relation上索引:
KEY `idx_outbound_no` (`OUTBOUND_NO`),
KEY `idx_sub_order_no` (`SUB_ORDER_NO`) 表ob_batch_d上索引:
KEY `idx_update_time` (`UPDATE_TIME`),
KEY `idx_ob_outbound_batch_d_batch_no` (`BATCH_NO`),
KEY `idx_ORDER_GROUP_ID` (`ORDER_GROUP_ID`), 表ob_batch_m上索引:
KEY `idx_update_time` (`UPDATE_TIME`),
KEY `idx_BATCH_NO` (`BATCH_NO`),
KEY `idx_BEAT_NO` (`BEAT_NO`),
KEY `idx_BATCH_TYPE_OPT_STATUS` (`BATCH_TYPE`,`OPT_STATUS`),
KEY `ix_SEND_FLAG` (`SEND_FLAG`)
查看执行计划为:
+----+-------------+-------+------------+------+----------------------------------+----------------------------------+---------+--------------------+-------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+------+----------------------------------+----------------------------------+---------+--------------------+-------+----------+-------------+
| 1 | SIMPLE | r | NULL | ref | idx_outbound_no,idx_sub_order_no | idx_outbound_no | 92 | const | 4 | 1.25 | Using where |
| 1 | SIMPLE | m | NULL | ref | idx_BATCH_NO,ix_SEND_FLAG | ix_SEND_FLAG | 2 | const | 54292 | 5.07 | Using where |
| 1 | SIMPLE | d | NULL | ref | idx_ob_outbound_batch_d_batch_no | idx_ob_outbound_batch_d_batch_no | 92 | ob_task.m.BATCH_NO | 16 | 1.00 | Using where |
+----+-------------+-------+------------+------+----------------------------------+----------------------------------+---------+--------------------+-------+----------+-------------+
本着直觉判定使用索引ix_SEND_FLAG但影响行数为54292步骤存在问题,虽然过滤条件中包含SEND_FLAG=0且列SEND_FLAG上有索引,但选择性较差,初步断定查询走错索引导致。
尝试1:删除列SEND_FLAG上索引,迫使查询走列BATCH_NO上索引,删除列SEND_FLAG上索引后,执行计划变为:
+----+-------------+-------+------------+-------+----------------------------------+----------------------------------+---------+--------------------+--------+----------+---------------------------------------------------------------------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+-------+----------------------------------+----------------------------------+---------+--------------------+--------+----------+---------------------------------------------------------------------------+
| 1 | SIMPLE | r | NULL | ref | idx_outbound_no,idx_sub_order_no | idx_outbound_no | 92 | const | 4 | 1.25 | Using where |
| 1 | SIMPLE | m | NULL | range | idx_BATCH_NO | idx_BATCH_NO | 92 | NULL | 146187 | 9.99 | Using index condition; Using where; Using join buffer (Block Nested Loop) |
| 1 | SIMPLE | d | NULL | ref | idx_ob_outbound_batch_d_batch_no | idx_ob_outbound_batch_d_batch_no | 92 | ob_task.m.BATCH_NO | 16 | 1.00 | Using where |
+----+-------------+-------+------------+-------+----------------------------------+----------------------------------+---------+--------------------+--------+----------+---------------------------------------------------------------------------+
查询影响行数变得更高,性能更差。
尝试2:检查INNER JOIN 关联列和WHERE条件列上的数据类型,排除隐式转换导致。
尝试3: 去除与ob_batch_m的所有相关进行,仅剩表ob_relation和ob_batch_d做INNER JOIN,其执行计划为:
SELECT COUNT(DISTINCT d.batch_no)
FROM ob_relation r
INNER JOIN ob_batch_d d
ON r.sub_order_no = d.outbound_no
WHERE r.production_mode =1
AND r.yn=0
AND r.outbound_no ='xxxx2156'
AND d.yn=0 +----+-------------+-------+------------+------+----------------------------------+-----------------+---------+-------+---------+----------+----------------------------------------------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+------+----------------------------------+-----------------+---------+-------+---------+----------+----------------------------------------------------+
| 1 | SIMPLE | r | NULL | ref | idx_outbound_no,idx_sub_order_no | idx_outbound_no | 92 | const | 4 | 1.25 | Using where |
| 1 | SIMPLE | d | NULL | ALL | NULL | NULL | NULL | NULL | 4917114 | 1.00 | Using where; Using join buffer (Block Nested Loop) |
+----+-------------+-------+------------+------+----------------------------------+-----------------+---------+-------+---------+----------+----------------------------------------------------+
发现表ob_batch_d的关联条件上缺少索引导致。
问题总结:
查询中ob_relation和ob_batch_d关联,而ob_batch_d和ob_batch_m关联,但由于表ob_batch_d关联条件上没有索引且表ob_relation上WHERE过滤条件选择性极高,因此查询优化器将SQL转换为:
SELECT COUNT(DISTINCT m1.batch_no) FROM (
SELECT m.batch_no,d.outbound_no
FROM ob_batch_d d
INNER JOIN ob_batch_m m
ON d.batch_no = m.batch_no
WHERE d.yn=0
AND m.yn=0
AND m.SEND_FLAG=0
AND m.batch_no!='xxx00025984'
)AS m1
INNER JOIN (
SELECT r.sub_order_no
FROM ob_relation r
WHERE r.production_mode =1
AND r.yn=0
AND r.outbound_no ='xxxx2156'
)AS r1
ON m1.outbound_no=r1.sub_order_no
对于m1子查询内部,表ob_batch_m可以通过SEND_FLAG=0来过滤部分数据(虽然选择性较差),因此选择使用索引ix_SEND_FLAG,而表ob_batch_d上缺少索引的问题被“完美隐藏”。
在优化INNER JOIN操作时,通常需要先确定两表的关系(外表和内表),外表通过WHERE条件列来过滤数据,而内表通过关联条件列来定位数据。
如对于下列查询:
SELECT COUNT(1)
FROM ob_relation r
INNER JOIN ob_batch_d d
ON r.sub_order_no = d.outbound_no
WHERE r.outbound_no ='xxxx2156';
表ob_relation和表ob_batch_d做INNER JOIN操作
1、表ob_relation作为外表,可以通过outbound_no ='xxxx2156'来过滤数据,因此需要在ob_relation(outbound_no)上创建索引。
2、表ob_batch_d作为内表,需要通过关联列outbound_no来定位数据,因此需要在ob_batch_d(outbound_no)上创建索引。
3、表ob_relation的关联条件sub_order_no并不需要单独作为索引第一列来创建索引,但在部分查中可以通过覆盖索引特性来优化查询,如上面查询中创建组合索引ob_relation(outbound_no,sub_order_no)能获得最佳性能。
总结:
有时候,经验能帮助你快速处理问题,但有些时候,经验能带你直接走入误区。
MySQL Index--关联条件列索引缺失导致执行计划性能不佳的更多相关文章
- SQL Server-聚焦使用索引和查询执行计划(五)
前言 上一篇我们讲了聚集索引对非聚集索引的影响,对数据库一直在强调的性能优化,所以这一节我们统筹讲讲利用索引来看看查询执行计划是怎样的,简短的内容,深入的理解,Always to review the ...
- mysql查询优化器为什么可能会选择错误的执行计划
有可能导致mysql优化器选择错误的执行计划的原因如下: A:统计信息不准确,mysql依赖存储引擎为其提供的统计信息来评估成本,然而有的存储引擎提供的信息是准确的,有的引擎提供的可能就偏差很大,如: ...
- SQL Tuning 基础概述10 - 体会索引的常见执行计划
在<SQL Tuning 基础概述05 - Oracle 索引类型及介绍>的1.5小节,提到了几种"索引的常见执行计划": INDEX FULL SCAN:索引的全扫描 ...
- SQL Server-聚焦使用索引和查询执行计划
前言 上一篇我们讲了聚集索引对非聚集索引的影响,对数据库一直在强调的性能优化,所以这一节我们统筹讲讲利用索引来看看查询执行计划是怎样的,简短的内容,深入的理解,Always to review the ...
- MongoDB性能篇之创建索引,组合索引,唯一索引,删除索引和explain执行计划
这篇文章主要介绍了MongoDB性能篇之创建索引,组合索引,唯一索引,删除索引和explain执行计划的相关资料,需要的朋友可以参考下 一.索引 MongoDB 提供了多样性的索引支持,索引信息被保存 ...
- MySQL 索引管理与执行计划
1.1 索引的介绍 索引是对数据库表中一列或多列的值进行排序的一种结构,使用索引可快速访问数据库表中的特定信息.如果想按特定职员的姓来查找他或她,则与在表中搜索所有的行相比,索引有助于更快地获取信息. ...
- MySQL学习【第七篇索引管理及执行计划】
一.索引介绍 1.什么是索引? 索引由如字典,目的就是为了更快寻找到要找的内容. 令搜索查询的数据更有目的性,从而提高数据检索的能力 2.索引类型介绍 1.BTREE: B+树索引 2.HASH: H ...
- 第六章· MySQL索引管理及执行计划
一.索引介绍 1.什么是索引 1)索引就好比一本书的目录,它能让你更快的找到自己想要的内容. 2)让获取的数据更有目的性,从而提高数据库检索数据的性能. 2.索引类型介绍 1)BTREE:B+树索引 ...
- Mysql索引、explain执行计划
1.索引的使用场景 哪些情况使用索引: 1.主键自动建立唯一索引 2.频繁作为查询条件的字段应该创建索引 where 3.多表关联查询中,关联字段应该创建索引on两边都要创建索引 select * f ...
随机推荐
- redis 使用redis Desktop manger进行远程进行链接
1.修改redis.conf文件: a.去掉bind:127.0.0.0 b.protected mode 模式改成 no 2.重启redis /etc/init.d/redis restart 3. ...
- typescript - 9.装饰器
装饰器:装饰器是一种特殊类型的声明,它能够被附加到类声明,方法,属性或参数上,可以修改类的行为. 通俗的讲装饰器就是一个方法,可以注入到类.方法.属性参数上来扩展类.属性.方法.参数的功能. 常见的装 ...
- ISO/IEC 9899:2011 引言
引言 1.伴随着新的设备以及扩展字符集的引入,可能会将新的特性添加到此国际标准中.在此语言和库条款中的子条款提醒了实现者与程序员可能会与将来所新增特性产生冲突的用法,尽管它们现在本身是合法有效的. 2 ...
- springboot 整合Elasticsearch
Elasticsearch Elasticsearch 是一个分布式.可扩展.实时的搜索与数据分析引擎. 它能从项目一开始就赋予你的数据以搜索.分析和探索的能力,可用于实现全文搜索和实时数据统计. 在 ...
- OpenShift 4.1 基本问题探索
因为在OpenShift 4.1环境中不建议直接登录集群主机操作,因此很多操作可能需要在外部的Client VM上完成.当然用rhel的worker node的同事也可以和原来习惯保持一致. 这里记录 ...
- 【Linux开发】【CUDA开发】Ubuntu上安装NVIDIA显卡驱动
机型为戴尔Vostro3900 显卡型号为GTX 745 对于Nvidia显卡的驱动,如今很多Linux发行版会默认使用名为nouveau的驱动程序.Nouveau是由第三方为Nvidia开发的一 ...
- vs中调试程序查看变量在内存中的内容的方法
vs中调试程序 查看变量在内存中的内容的方法 https://blog.csdn.net/guojg1988/article/details/42922149 原文链接:http://www.sows ...
- 第4/7Beta冲刺
1.团队成员 成员姓名 成员学号 秦裕航 201731062432(组长) 刘东 201731062227 张旭 201731062129 王伟 201731062214 2.SCRU部分 2.1各成 ...
- QT 5.x 网络资源集锦
github上的好书:太好了: http://qmlbook.github.io/en/ch01/index.html 论坛: 基于QT的音乐创作软件:(是不是可以跟谷歌的深度学习艺术项目结合) ht ...
- hashMap常见问题
[解析hashMap的源码实现] 点击进入hashMap的源码实现 0.谈谈对hashMap的理解? 从底层结构.存取.扩容.冲突.实现原理.源码等方面说明. 1.你知道哪些常用的Map集合 ...