某系统反馈慢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. PostgreSQL中的partition-wise join

    与基于继承的分区(inheritance-based partitioning)不同,PostgreSQL 10中引入的声明式分区对数据如何划分没有任何影响.PostgreSQL 11的查询优化器正准 ...

  2. 【LeetCode算法-27】Remove Element

    LeetCode第27题 Given an array nums and a value val, remove all instances of that value in-place and re ...

  3. [LeetCode] 504. Base 7 基数七

    Given an integer, return its base 7 string representation. Example 1: Input: 100 Output: "202&q ...

  4. [LeetCode] 568. Maximum Vacation Days 最大化休假日

    LeetCode wants to give one of its best employees the option to travel among N cities to collect algo ...

  5. 【视频开发】EasyIPCamera通过RTSP协议接入海康、大华等摄像机,摒弃私有SDK接入弊端

    近期工作中需要开发一套视频监控系统,实现WEB端.手机APP端预览局域网内的道路监控摄像机,我负责一些后台服务的开发工作. 由于之前项目中的程序都是采用私有协议.各摄像机厂商的SDK进行视频监控系统开 ...

  6. springboot实战日记(一)数据库基本信息

    摘要:基于spring boot的后端实现,开发一个微信小程序点餐系统,主要是写写思路和遇到的问题以及分享读到的好文章. 项目分析: 1.角色划分,就是开有什么人使用这个系统,买家(手机端),卖家(p ...

  7. 第1/7Beta冲刺

    1.团队成员 成员姓名 成员学号 秦裕航 201731062432(组长) 刘东 201731062227 张旭 201731062129 王伟 201731062214 2.SCRU部分 2.1各成 ...

  8. MinGW ,GNU 是什么

    MinGW : Minimalist GNU for Windows MinGW(Minimalist GNU For Windows)是个精简的Windows平台下的 C/C++.ADA及Fortr ...

  9. [转]综述论文翻译:A Review on Deep Learning Techniques Applied to Semantic Segmentation

    近期主要在学习语义分割相关方法,计划将arXiv上的这篇综述好好翻译下,目前已完成了一部分,但仅仅是尊重原文的直译,后续将继续完成剩余的部分,并对文中提及的多个方法给出自己的理解. _论文地址:htt ...

  10. wmi的作用

    WMI是Windows 2K/XP管理系统的核心,对于其他的Win32操作系统,WMI是一个有用的插件. WMI的作用是: ①通过它可以访问.配置.管理和监视几乎所有的Windows资源,比如用户可以 ...