首页 > 数据库 >重现一条简单SQL的优化过程

重现一条简单SQL的优化过程

时间：2023-03-31 10:23:33浏览次数：37  
标签：11 DEFAULT 索引 int 重现 SQL NULL 优化 id

  • GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。
  • GreatSQL是MySQL的国产分支版本，使用上与MySQL一致。
  • 作者： JennyYu
  • 文章来源：GreatSQL社区投稿

背景

接到客户诉求说一条SQL长时间运行不出结果，让给看看怎么回事，SQL不复杂，优化措施也不复杂，但是要想SQL达到最优状态，也是需要经过一番考量并做出选择的。下面借实验还原一下此SQL优化过程。

实验：

数据库环境：MySQL5.7.39

测试表结构如下：

mysql> show create table t_1\G
*************************** 1. row ***************************
       Table: t_1
Create Table: CREATE TABLE `t_1` (
  `w_id` int(11) DEFAULT NULL,
  `w_name` varchar(10) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
1 row in set (0.00 sec)


mysql> show create table t_2\G
*************************** 1. row ***************************
       Table: t_2
Create Table: CREATE TABLE `t_2` (
  `i_id` int(11) NOT NULL,
  `i_name` varchar(24) DEFAULT NULL,
  `i_price` decimal(5,2) DEFAULT NULL,
  `i_data` varchar(50) DEFAULT NULL,
  `i_im_id` int(11) NOT NULL,
  PRIMARY KEY (`i_im_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
1 row in set (0.00 sec)

mysql> show create table t_3\G
*************************** 1. row ***************************
       Table: t_3
Create Table: CREATE TABLE `t_3` (
  `s_w_id` int(11) NOT NULL,
  `s_i_id` int(11) NOT NULL,
  `s_quantity` int(11) DEFAULT NULL,
  `s_ytd` int(11) DEFAULT NULL,
  `s_order_cnt` int(11) DEFAULT NULL,
  `s_remote_cnt` int(11) DEFAULT NULL,
  `s_data` varchar(50) DEFAULT NULL,
  `s_dist_01` char(24) DEFAULT NULL,
  `s_dist_02` char(24) DEFAULT NULL,
  `s_dist_03` char(24) DEFAULT NULL,
  `s_dist_04` char(24) DEFAULT NULL,
  `s_dist_05` char(24) DEFAULT NULL,
  `s_dist_06` char(24) DEFAULT NULL,
  `s_dist_07` char(24) DEFAULT NULL,
  `s_dist_08` char(24) DEFAULT NULL,
  `s_dist_09` char(24) DEFAULT NULL,
  `s_dist_10` char(24) DEFAULT NULL,
  `t_2_id` int(11) DEFAULT NULL,
  `t_1_id` int(11) DEFAULT NULL,
  PRIMARY KEY (`s_w_id`,`s_i_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
1 row in set (0.00 sec)

Create Table: CREATE TABLE `t_4` (
  `w_name` varchar(10) DEFAULT NULL,
  `s_i_id` int(11) NOT NULL,
  `s_quantity` int(11) DEFAULT NULL,
  `s_ytd` int(11) DEFAULT NULL,
  `s_order_cnt` int(11) DEFAULT NULL,
  `s_remote_cnt` int(11) DEFAULT NULL,
  `s_data` varchar(50) DEFAULT NULL,
  `t_2_id` int(11) DEFAULT NULL,
  `i_name` varchar(24) DEFAULT NULL,
  `i_price` decimal(5,2) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

其中t_1表25条记录，t_2表100条记录，t_3表500万条数据。我这里实验数据量少些，客户实际业务表数据量分别是（30，150，2700万）。t_4表为一个历史数据归档表，用于插入数据。

SQL文本展示如下：

insert into t_4
SELECT
  c.w_name,
  a.s_i_id,
  a.s_quantity,
  a.s_ytd,
  a.s_order_cnt,
  a.s_remote_cnt,
  a.s_data,
  a.t_2_id,
  b.i_name,
  b.i_price
FROM
 t_3 a,
 t_2 b,
 t_1 c
WHERE
 a.t_2_id = b.i_id
and a.t_1_id = c.w_id
and a.s_ytd = 0;

查看语句中select部分的执行计划如下图所示：

图片

看到这个计划，就想对数据库说一句："您辛苦了!"。

优化器选择先对两个小表c，b进行关联，然后得到的结果集再与大表a进行关联，因为语句中c，b两个表没有字段进行直接关联，所以这两个表连接后的结果集是一个笛卡尔积25 *100=2500，因为大表的关联字段上没有索引，所以需要对最内层的大表全表扫描2500次。

这是不是一个大工程呢？数据库任劳任怨，你让它干，它就干，只要你等得起就可以。事实上我们是没有耐心等的。我本来还想看看数据库到底用多久才能给出结果，等了10分钟，实在没有耐心继续等下去了。

这条SQL不复杂吧，就是三张表进行关联，但是关联字段上都没有索引，都进行了全表扫描。那么解决措施就是加索引，但是索引怎么加就需要做出选择了。

有同事就提出这个SQL在大表上全表扫描2500次，在大表的关联字段上加上索引就可以了，看到这里，你有没有认同这个见解呢？我想应该有很多小伙伴是认同的。

不错，给大表加上索引就不用全表扫描了，首先大表加索引，会锁表很长时间，这个索引在客户的生产环境须等到变更窗口才能加，客户等不及，其次你有考虑过这真的是最好的办法吗？

因为我这是实验环境，可以随时给大表加索引，那接下来我们就给大表加上索引试试效果。

mysql> alter table t_3 add key(t_1_id,t_2_id);
Query OK, 0 rows affected (28.35 sec)
Records: 0  Duplicates: 0  Warnings: 0

索引加好之后，执行计划如下：

图片

可以看出优化器并没有选择走索引，依然是使用BNL优化策略，进行全表扫描，为什么不走索引呢？应该是优化器认为索引扫描的成本高于全表扫描的成本，因为这条语句最终结果要返回大表的90%以上的数据，走索引后回表代价是很高的。这一点我们是不认同优化器的，怎么着2500次全表扫描也比每次通过索引范围扫描的代价要高呀，好吧，既然不认同，那么使用force index来干涉优化器决策，让它使用索引。

执行计划如下图所示：

图片

执行计划中显示索引用上了，那实际执行效果如何呢？

mysql> insert into t_4
    -> SELECT
    ->   c.w_name,
    ->   a.s_i_id,
    ->   a.s_quantity,
    ->   a.s_ytd,
    ->   a.s_order_cnt,
    ->   a.s_remote_cnt,
    ->   a.s_data,
    ->   a.t_2_id,
    ->   b.i_name,
    ->   b.i_price
    -> FROM
    ->  t_3 a force index(t_1_id),
    ->  t_2 b,
    ->  t_1 c
    -> WHERE
    ->  a.t_2_id = b.i_id
    -> and a.t_1_id = c.w_id
    -> and a.s_ytd = 0;
Query OK, 4800000 rows affected (4 min 43.57 sec)
Records: 4800000  Duplicates: 0  Warnings: 0

确实效率不错，500万数据需要4 min 43.57 sec，生产环境的2700万数据大概需要半个小时左右。

但这是不是效率最高的办法呢，因为最终结果集会返回大表的90%以上的数据，所以需要对大量的索引数据回表，因为回表是会产生随机IO的，这个回表代价确实比较高，优化器默认也没有选择这种执行计划。如果我们给小表的关联字段上加索引会是什么效果呢？

接下来我给两个小表的关联字段上加了索引。

mysql> alter table t_2 add key(i_id);
Query OK, 0 rows affected (0.05 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> alter table t_1 add key(w_id);
Query OK, 0 rows affected (0.03 sec)
Records: 0  Duplicates: 0  Warnings: 0

我们去掉大表的force index，不干涉优化器，让优化器自己做决策。执行计划如下：

图片

上图的执行计划显示，优化器选择了对大表全表扫描，大表做驱动表，驱动两个小表。那这样的实际效果如何呢？

mysql> insert into t_4
    -> SELECT
    ->   c.w_name,
    ->   a.s_i_id,
    ->   a.s_quantity,
    ->   a.s_ytd,
    ->   a.s_order_cnt,
    ->   a.s_remote_cnt,
    ->   a.s_data,
    ->   a.t_2_id,
    ->   b.i_name,
    ->   b.i_price
    -> FROM
    ->  t_3 a,
    ->  t_2 b,
    ->  t_1 c
    -> WHERE
    ->  a.t_2_id = b.i_id
    -> and a.t_1_id = c.w_id
    -> and a.s_ytd = 0;
Query OK, 4800000 rows affected (1 min 59.06 sec)
Records: 4800000  Duplicates: 0  Warnings: 0

这种方式耗时1min 59.06sec ，效率提高1倍多，生产环境的大数据量，效率提升应该更明显。果然采用大表驱动小表这种方式效率提高了，优化器的选择是对的。

选择这种方式的好处：

1.SQL的执行效率高一倍

2.节省空间，因为大表的索引会占用很大的磁盘空间。

3.响应及时，避免了必须等到变更窗口才能加索引的麻烦。

4.不用修改SQL语句

该如何选择是不是很清楚了呢？

到这里似乎优化就结束了，但是如果想要精益求精，追求极致的话，小表上的索引可以建成覆盖索引，防止小表回表取数据。

mysql> alter table t_1 drop key w_id;
Query OK, 0 rows affected (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> alter table t_2 drop key i_id;
Query OK, 0 rows affected (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> alter table t_2 add key(i_id,i_name,i_price);
Query OK, 0 rows affected (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> alter table t_1 add key(w_id,w_name);
Query OK, 0 rows affected (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0

执行效果如下：

mysql> insert into t_4
    -> SELECT
    ->   c.w_name,
    ->   a.s_i_id,
    ->   a.s_quantity,
    ->   a.s_ytd,
    ->   a.s_order_cnt,
    ->   a.s_remote_cnt,
    ->   a.s_data,
    ->   a.t_2_id,
    ->   b.i_name,
    ->   b.i_price
    -> FROM
    ->  t_3 a,
    ->  t_2 b,
    ->  t_1 c
    -> WHERE
    ->  a.t_2_id = b.i_id
    -> and a.t_1_id = c.w_id
    -> and a.s_ytd = 0;
Query OK, 4800000 rows affected (1 min 38.99 sec)
Records: 4800000  Duplicates: 0  Warnings: 0

可以看出，小表上的索引建成覆盖索引，耗时又缩短了20秒，执行效率更高了。

至此该条SQL的优化结束。

总结

1.本条SQL的最终执行计划是大表驱动小表，这也算是给上篇文章《NL连接一定是小表驱动大表效率高吗》提供了一个案例。

2.优化措施可能有很多不同的选择，要根据实际情况选择最优的，不要草率做出决定。

3.精益求精是优化的极致，但是有时候也是需要做出折中选择的，达到业务运行的要求是目的，这点以后遇到案例再说。

Enjoy GreatSQL

标签：11,DEFAULT,索引,int,重现,SQL,NULL,优化,id
From： https://www.cnblogs.com/greatsql/p/17275418.html

相关文章

  • 力扣601(MySQL)-体育馆的人的流量（困难）
    题目：表：Stadium编写一个SQL查询以找出每行的人数大于或等于100且id连续的三行或更多行记录。返回按visit_date升序排列的结果表。查询结果格式如下所示示例1：  解释：id为5、6、7、8的四行id连续，并且每行都有>=100的人数记录。请注意，即使第7行和第8行......
  • MySQL按日期分组统计（按天统计，按月统计）
    按月统计（一）selectdate_format(create_time,'%Y-%m')mont,count(*)counfromt_contentgroupbydate_format(create_time,'%Y-%m');按天统计（二）selectdate_format(create_time,'%Y-%m-%d')dat,count(*)counfromt_contentgroupby......
  • SQL case when then else end 组合用法~
     在数据表设计的时候,我们经常会用到bit,int等字段来表示一些值,例如下面表中我们性别列用0表示男,1表示女 IdNameGender1张三02李四1 我们直接查询时候,想把0变成男,1变成女。selectIdas编号,Nameas姓名,casethenGender=0when'男't......
  • T-SQL语言的语法以及操作
    使用脚本创建数据库usemastergocreatedatabase数据库名on primary(-主要数据文件的设置name=filenamesizefilegrowth)logon(--日志文件的设置namefilenamesizefilegrowth)go T-SQL创建表1.表信息准备产品信息表:标识列，int编号varchar(50)名称 ......
  • sqlmap工具学习
    tryhackme：sqlmapgithub：https://github.com/sqlmapproject/sqlmapkali集成参数介绍sqlmap-h_____H________[(]___________{1.7.2#stable}|_-|.["]|.'|.||___|_[']_|_|_|__,|_||_|V...|_|https://s......
  • MySQL数据库面试题
    数据库三大范式是什么第一范式：每个列都不可以再拆分。第二范式：在第一范式的基础上，非主键列完全依赖于主键，而不能是依赖于主键的一部分。第三范式：在第二范式的基础上，非主键列只依赖于主键，不依赖于其他非主键。在设计数据库结构的时候，要尽量遵守三范式，如果不遵守，必须有足够的理......
  • MySQL主键的一些思考
    MySQL创建表的时候可以不设置主键吗？MySQL创建表的时候是可以不主动设置主键的，但是表是一定需要一个主键的，MySQL会主动将第一个不为null的唯一索引设置为主键为什么MySQL推荐使用自增id作为主键？MySQL官方推荐不要使用uuid或者不连续不重复的雪花作为主键，而是使用连续自增的主键id......
  • SQL语言分类
    1)DQL数据查询语言Select列From表名where条件2)DML数据操纵语言Insert插入  insertinto表名(列.列，..)  values(对应的值，对应的值)Update更新update表名set列名=值，列名=值where条件Delete删除deletefrom表名where条件 3)DDL数据定义语言创建数据库及其对......
  • Oracle PL/SQL 自治事务
    自治事务是PL/SQL静态SQL的一个特性，可声明于存储过程、函数或触发器中。它是和主事务分开的事务，可以独立执行事务，不与主事务共享锁、资源，不受主事务提交的影响。自治事务可以用来记录日志，记录计数值，而不受主事务回滚的影响。--创建自治事务的存储过程createorreplaceprocedur......
  • NoSQL之Redis配置与优化
    一、数据库类型1.关系型数据库关系型数据库是一个结构化的数据库，创建在关系模型(二维表格模型)基础上，一般面向于记录。SQL语句(标准数据查询语言)就是一种基于关系型数据库的语言，用于执行对关系型数据库中数据的检索和操作。主流的关系型数据库包括Oracle、MySQL、SQLSe......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99