某系统反馈慢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--关联条件列索引缺失导致执行计划性能不佳的更多相关文章

  1. SQL Server-聚焦使用索引和查询执行计划(五)

    前言 上一篇我们讲了聚集索引对非聚集索引的影响,对数据库一直在强调的性能优化,所以这一节我们统筹讲讲利用索引来看看查询执行计划是怎样的,简短的内容,深入的理解,Always to review the ...

  2. mysql查询优化器为什么可能会选择错误的执行计划

    有可能导致mysql优化器选择错误的执行计划的原因如下: A:统计信息不准确,mysql依赖存储引擎为其提供的统计信息来评估成本,然而有的存储引擎提供的信息是准确的,有的引擎提供的可能就偏差很大,如: ...

  3. SQL Tuning 基础概述10 - 体会索引的常见执行计划

    在<SQL Tuning 基础概述05 - Oracle 索引类型及介绍>的1.5小节,提到了几种"索引的常见执行计划": INDEX FULL SCAN:索引的全扫描 ...

  4. SQL Server-聚焦使用索引和查询执行计划

    前言 上一篇我们讲了聚集索引对非聚集索引的影响,对数据库一直在强调的性能优化,所以这一节我们统筹讲讲利用索引来看看查询执行计划是怎样的,简短的内容,深入的理解,Always to review the ...

  5. MongoDB性能篇之创建索引,组合索引,唯一索引,删除索引和explain执行计划

    这篇文章主要介绍了MongoDB性能篇之创建索引,组合索引,唯一索引,删除索引和explain执行计划的相关资料,需要的朋友可以参考下 一.索引 MongoDB 提供了多样性的索引支持,索引信息被保存 ...

  6. MySQL 索引管理与执行计划

    1.1 索引的介绍 索引是对数据库表中一列或多列的值进行排序的一种结构,使用索引可快速访问数据库表中的特定信息.如果想按特定职员的姓来查找他或她,则与在表中搜索所有的行相比,索引有助于更快地获取信息. ...

  7. MySQL学习【第七篇索引管理及执行计划】

    一.索引介绍 1.什么是索引? 索引由如字典,目的就是为了更快寻找到要找的内容. 令搜索查询的数据更有目的性,从而提高数据检索的能力 2.索引类型介绍 1.BTREE: B+树索引 2.HASH: H ...

  8. 第六章· MySQL索引管理及执行计划

    一.索引介绍 1.什么是索引 1)索引就好比一本书的目录,它能让你更快的找到自己想要的内容. 2)让获取的数据更有目的性,从而提高数据库检索数据的性能. 2.索引类型介绍 1)BTREE:B+树索引 ...

  9. Mysql索引、explain执行计划

    1.索引的使用场景 哪些情况使用索引: 1.主键自动建立唯一索引 2.频繁作为查询条件的字段应该创建索引 where 3.多表关联查询中,关联字段应该创建索引on两边都要创建索引 select * f ...

随机推荐

  1. 如何打开uboot的函数debug()的开关,输出更多调试信息?

    答: 有两种方法: 一. 方法一 在文件<file>.c的首行加入以下内容: #define DEBUG #undef CONFIG_LOGLEVEL #define CONFIG_LOG ...

  2. SD-WAN基础---SD-WAN简单了解

    一:推文(摘录.转载自) 关于SD-WAN,你不得不了解的10个常识 那些让人怦然心动的SD-WAN功能(上) 那些让人怦然心动的SD-WAN功能(中) 二:SD-WAN是什么 SD-WAN,即软件定 ...

  3. latex怎样生成table字样和caption换行的表格

    \begin{table}  \caption{\newline The results of running algorithm parallel using MapReduce.} \hline  ...

  4. Kafka在zookeeper中存储结构和查看方式

    Zookeeper 主要用来跟踪Kafka 集群中的节点状态, 以及Kafka Topic, message 等等其他信息. 同时, Kafka 依赖于Zookeeper, 没有Zookeeper 是 ...

  5. 一码学程 10284 排队找bug 题解 单调队列 或者 线段树RMQ

    注:只是看到题目,未评测,所以不确定代码正确性,但是算法思路没有问题 描述 同学们的bug还真是多啊,orz... 春节期间大家存下的bug都来找肖老师解决了. 每个人都有bug,但是肖老师却只有一个 ...

  6. css选择器测试2-用ul和li简单排版

    之前的博文:测试了一些css样式的优先级,都是比较常见的选择器 ,这里测试一些其他一些选择方式. *:通配符,所有页面的元素都走这个.设置多个class:一个标签里不能有两个class,如果想要设置多 ...

  7. WARNING:Your password has expired --linux 用户密码过期

    今天在ssh 提示  WARNING:Your password has expired 设置用户到期时间 chage -M 36000 用户名 chage -l 用户名 #查看用户信息

  8. MySQL之表日志管理

    MySQL日志管理 mysql日志(默认存放在datadir): 同大多数关系型数据库一样,日志文件是MySQL数据库的重要组成部分.MySQL有几种不同的日志文件,通常包括错误日志文件,二进制日志, ...

  9. Spring中的@ImportResource

    简介 这个注解很简单,就是导入spring的xml配置文件 直接来看spring官方文档: In applications where @Configuration classes are the p ...

  10. LeetCode 563. 二叉树的坡度(Binary Tree Tilt) 38

    563. 二叉树的坡度 563. Binary Tree Tilt 题目描述 给定一个二叉树,计算整个树的坡度. 一个树的节点的坡度定义即为,该节点左子树的结点之和和右子树结点之和的差的绝对值.空结点 ...