服务器之家：专注于服务器技术及软件下载分享
分类导航

Mysql|Sql Server|Oracle|Redis|MongoDB|PostgreSQL|Sqlite|DB2|mariadb|

服务器之家 - 数据库 - Mysql - SQL优化教程之in与range查询

SQL优化教程之in与range查询

2021-03-13 18:44倾斜的镜子 Mysql

这篇文章主要介绍了给大家介绍了SQL优化之in与range查询的相关资料，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧

前言

《高性能MySQL》里面提及用in这种方式可以有效的替代一定的range查询，提升查询效率， 因为在一条索引里面，range字段后面的部分是不生效的（ps.需要考虑 ICP） 。MySQL优化器将in这种方式转化成  n*m 种组合进行查询，最终将返回值合并，有点类似union但是更高效。

MySQL在 IN() 组合条件过多的时候会发生很多问题。查询优化可能需要花很多时间，并消耗大量内存。新版本MySQL在组合数超过一定的数量就不进行计划评估了，这可能导致MySQL不能很好的利用索引。

这里的 一定数 在MySQL5.6.5以及以后的版本中是由eq_range_index_dive_limit这个参数控制 。默认设置是10，一直到5.7以后的版本默认修改为200，当然可以手动设置的。5.6手册说明如下：

The eq_range_index_dive_limit system variable enables you to configure the number of values at which the optimizer switches from one row estimation strategy to the other. To disable use of statistics and always use index dives, set eq_range_index_dive_limit to 0. To permit use of index dives for comparisons of up to N equality ranges, set eq_range_index_dive_limit to N + 1. eq_range_index_dive_limit is available as of MySQL 5.6.5. Before 5.6.5, the optimizer uses index dives, which is equivalent to eq_range_index_dive_limit=0.

换言之，

eq_range_index_dive_limit = 0 只能使用index dive

0 < eq_range_index_dive_limit <= N 使用index statistics

eq_range_index_dive_limit > N 只能使用index dive

在MySQL5.7版本中将默认值从10修改成200目的是为了尽可能的保证范围等值运算（IN()）执行计划尽量精准，因为IN()list的数量很多时候都是超过10的。

在MySQL的官方手册上有这么一句话:

the optimizer can estimate the row count for each range using dives into the index or index statistics.

大意:

优化器预估每个范围段－－如"a IN (10, 20, 30)" 视为等值比较, 括3个范围段实则简化为3个单值,分别是10,20,30－－中包括的元组数,用范围段来表示是因为 MySQL 的"range"扫描方式多数做的是范围扫描，此处单值可视为范围段的特例;

估计方法有2种:

  1. dive到index中即利用索引完成元组数的估算,简称index dive;
  2. index statistics:使用索引的统计数值,进行估算;

对比这两种方式

  1. index dive: 速度慢,但能得到精确的值（MySQL的实现是数索引对应的索引项个数，所以精确）
  2. index statistics: 速度快,但得到的值未必精确

简单说，**选项 eq_range_index_dive_limit 的值设定了 IN列表中的条件个数上线，超过设定值时，会将执行计划从 index dive 变成 index statistics **。

为什么要区分这2种方式呢?

  1. 查询优化器会使用代价估算模型计算每个计划的代价,选择其中代价最小的
  2. 单表扫描时,需要计算代价;所以单表的索引扫描也需要计算代价
  3. 单表的计算公式通常是:  代价 = 元组数 * IO平均值
  4. 所以不管是哪种扫描方式,都需要计算元组数
  5. 当遇到“a IN (10, 20, 30)”这样的表达式的时候，发现a列存在索引，则需要看这个索引可以扫描到的元组数由多少而计算其索引扫描代价，所以就用到了本文提到的“index dive”、“index statistics”这2种方式。

讨论主题

  1. range查询与索引使用
  2. eq_range_index_dive_limit的说明

range查询与索引使用

SQL如下：

?
1
SELECT * FROM pre_forum_post WHERE tid=7932552 AND invisible IN('0','-2') ORDER BY dateline DESC LIMIT 10;

索引如下：

?
1
2
3
4
5
6
7
8
PRIMARY(tid,position),
pid(pid),
fid(tid),
displayorder(tid,invisible,dateline)
first(tid,first)
new_auth(authorid,invisible,tid)
idx_dt(dateline)
mul_test(tid,invisible,dateline,pid)

看下执行计划：

?
1
2
3
4
5
6
7
8
root@localhost 16:08:27 [ultrax]> explain SELECT * FROM pre_forum_post WHERE tid=7932552 AND `invisible` IN('0','-2')
 -> ORDER BY dateline DESC LIMIT 10;
+----+-------------+----------------+-------+-------------------------------------------+--------------+---------+------+------+---------------------------------------+
| id | select_type | table | type | possible_keys  | key | key_len | ref | rows | Extra   |
+----+-------------+----------------+-------+-------------------------------------------+--------------+---------+------+------+---------------------------------------+
| 1 | SIMPLE | pre_forum_post | range | PRIMARY,displayorder,first,mul_test,idx_1 | displayorder | 4 | NULL | 54 | Using index condition; Using filesort |
+----+-------------+----------------+-------+-------------------------------------------+--------------+---------+------+------+---------------------------------------+
1 row in set (0.00 sec)

MySQL优化器认为这是一个range查询，那么(tid,invisible,dateline)这条索引中，dateline字段肯定用不上了，也就是说这个SQL最后的排序肯定会生成一个临时结果集，然后再结果集里面完成排序，而不是直接在索引中直接完成排序动作，于是我们尝试增加了一条索引。

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
root@localhost 16:09:06 [ultrax]> alter table pre_forum_post add index idx_1 (tid,dateline);
Query OK, 20374596 rows affected, 0 warning (600.23 sec)
Records: 0 Duplicates: 0 Warnings: 0
root@localhost 16:20:22 [ultrax]> explain SELECT * FROM pre_forum_post force index (idx_1) WHERE tid=7932552 AND `invisible` IN('0','-2') ORDER BY dateline DESC LIMIT 10;
+----+-------------+----------------+------+---------------+-------+---------+-------+--------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+----------------+------+---------------+-------+---------+-------+--------+-------------+
| 1 | SIMPLE | pre_forum_post | ref | idx_1 | idx_1 | 3 | const | 120646 | Using where |
+----+-------------+----------------+------+---------------+-------+---------+-------+--------+-------------+
1 row in set (0.00 sec)
root@localhost 16:22:06 [ultrax]> SELECT sql_no_cache * FROM pre_forum_post WHERE tid=7932552 AND `invisible` IN('0','-2') ORDER BY dateline DESC LIMIT 10;
...
10 rows in set (0.40 sec)
root@localhost 16:23:55 [ultrax]> SELECT sql_no_cache * FROM pre_forum_post force index (idx_1) WHERE tid=7932552 AND `invisible` IN('0','-2') ORDER BY dateline DESC LIMIT 10;
...
10 rows in set (0.00 sec)

实验证明效果是极好的，其实不难理解，上面我们就说了in()在MySQL优化器里面是以多种组合方式来检索数据的，如果加了一个排序或者分组那势必只能在临时结果集上操作，也就是说索引里面即使包含了排序或者分组的字段依然是没用的。唯一不满的是MySQL优化器的选择依然不够靠谱。

总结下：在MySQL查询里面使用in()，除了要注意in()list的数量以及eq_range_index_dive_limit的值以外（具体见下），还要注意如果SQL包含排序/分组/去重等等就需要注意索引的使用。

eq_range_index_dive_limit的说明

还是上面的案例，为什么idx_1无法直接使用？需要使用hint强制只用这个索引呢？这里我们首先看下eq_range_index_dive_limit的值。

?
1
2
3
4
5
6
7
root@localhost 22:38:05 [ultrax]> show variables like 'eq_range_index_dive_limit';
+---------------------------+-------+
| Variable_name | Value |
+---------------------------+-------+
| eq_range_index_dive_limit | 2 |
+---------------------------+-------+
1 row in set (0.00 sec)

根据我们上面说的这种情况0 < eq_range_index_dive_limit <= N使用index statistics，那么接下来我们用OPTIMIZER_TRACE来一看究竟。

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
{
 "index": "displayorder",
 "ranges": [
 "7932552 <= tid <= 7932552 AND -2 <= invisible <= -2",
 "7932552 <= tid <= 7932552 AND 0 <= invisible <= 0"
 ],
 "index_dives_for_eq_ranges": false,
 "rowid_ordered": false,
 "using_mrr": false,
 "index_only": false,
 "rows": 54,
 "cost": 66.81,
 "chosen": true
}
// index dive为false，最终chosen是true
...
{
 "index": "idx_1",
 "ranges": [
 "7932552 <= tid <= 7932552"
 ],
 "index_dives_for_eq_ranges": true,
 "rowid_ordered": false,
 "using_mrr": false,
 "index_only": false,
 "rows": 120646,
 "cost": 144776,
 "chosen": false,
 "cause": "cost"
}

我们可以看到displayorder索引的cost是66.81，而idx_1的cost是120646，而最终MySQL优化器选择了displayorder这条索引。那么如果我们把eq_range_index_dive_limit设置>N是不是应该就会使用index dive计算方式，得到更准确的执行计划呢？

?
1
2
3
4
5
6
7
8
9
root@localhost 22:52:52 [ultrax]> set eq_range_index_dive_limit = 3;
Query OK, 0 rows affected (0.00 sec)
root@localhost 22:55:38 [ultrax]> explain SELECT * FROM pre_forum_post WHERE tid=7932552 AND `invisible` IN('0','-2') ORDER BY dateline DESC LIMIT 10;
+----+-------------+----------------+------+-------------------------------------------+-------+---------+-------+--------+-------------+
| id | select_type | table | type | possible_keys  | key | key_len | ref | rows | Extra |
+----+-------------+----------------+------+-------------------------------------------+-------+---------+-------+--------+-------------+
| 1 | SIMPLE | pre_forum_post | ref | PRIMARY,displayorder,first,mul_test,idx_1 | idx_1 | 3 | const | 120646 | Using where |
+----+-------------+----------------+------+-------------------------------------------+-------+---------+-------+--------+-------------+
1 row in set (0.00 sec)

optimize_trace结果如下

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
{
 "index": "displayorder",
 "ranges": [
 "7932552 <= tid <= 7932552 AND -2 <= invisible <= -2",
 "7932552 <= tid <= 7932552 AND 0 <= invisible <= 0"
 ],
 "index_dives_for_eq_ranges": true,
 "rowid_ordered": false,
 "using_mrr": false,
 "index_only": false,
 "rows": 188193,
 "cost": 225834,
 "chosen": true
}
...
{
 "index": "idx_1",
 "ranges": [
 "7932552 <= tid <= 7932552"
 ],
 "index_dives_for_eq_ranges": true,
 "rowid_ordered": false,
 "using_mrr": false,
 "index_only": false,
 "rows": 120646,
 "cost": 144776,
 "chosen": true
}
...
 "cost_for_plan": 144775,
 "rows_for_plan": 120646,
 "chosen": true

在备选索引选择中两条索引都被选择，在最后的逻辑优化中选在了代价最小的索引也就是idx_1 以上就是在等值范围查询中eq_range_index_dive_limit的值怎么影响MySQL优化器计算开销，从而影响索引的选择。另外我们可以通过profiling来看看优化器的统计耗时：

index dive

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
+----------------------+----------+
| Status | Duration |
+----------------------+----------+
| starting | 0.000048 |
| checking permissions | 0.000004 |
| Opening tables | 0.000015 |
| init  | 0.000044 |
| System lock | 0.000009 |
| optimizing | 0.000014 |
| statistics | 0.032089 |
| preparing | 0.000022 |
| Sorting result | 0.000003 |
| executing | 0.000003 |
| Sending data | 0.000101 |
| end  | 0.000004 |
| query end | 0.000002 |
| closing tables | 0.000009 |
| freeing items | 0.000013 |
| cleaning up | 0.000012 |
+----------------------+----------+

index statistics

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
+----------------------+----------+
| Status | Duration |
+----------------------+----------+
| starting | 0.000045 |
| checking permissions | 0.000003 |
| Opening tables | 0.000014 |
| init  | 0.000040 |
| System lock | 0.000008 |
| optimizing | 0.000014 |
| statistics | 0.000086 |
| preparing | 0.000016 |
| Sorting result | 0.000002 |
| executing | 0.000002 |
| Sending data | 0.000016 |
| Creating sort index | 0.412123 |
| end  | 0.000012 |
| query end | 0.000004 |
| closing tables | 0.000013 |
| freeing items | 0.000023 |
| cleaning up | 0.000015 |
+----------------------+----------+

可以看到当eq_range_index_dive_limit加大使用index dive时，优化器统计耗时明显比ndex statistics方式来的长，但最终它使用了作出了更合理的执行计划。统计耗时0.032089s vs .000086s，但是SQL执行耗时却是约0.03s vs 0.41s。

附：

如何使用optimize_trace

?
1
2
3
set optimizer_trace='enabled=on';
 
select * from information_schema.optimizer_traceG

注：optimizer_trace建议只在session模式下开启调试即可

如何使用profile

?
1
2
3
4
5
set profiling=ON;
执行sql;
show profiles;
show profile for query 2;
show profile block io,cpu for query 2;

另外还可以看到memory,swaps,context switches,source 等信息

参考资料

[1]MySQL SQL优化系列之 in与range 查询

http://www.zzvips.com/article/147157.html

[2]MySQL物理查询优化技术---index dive辨析

http://blog.163.com/li_hx/blog/static/18399141320147521735442/

到此这篇关于SQL优化教程之in与range查询的文章就介绍到这了,更多相关SQL优化之in与range查询内容请搜索服务器之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持服务器之家！

原文链接：https://mp.weixin.qq.com/s/CjA5g0ex4_84ts2FuXzxfg

  • 优化
  • in
  • range
  • SQL

    • 延伸 · 阅读

    精彩推荐
    • Mysqlsphinxql如何得到结果数及show meta的详细说明

      sphinxql如何得到结果数及show meta的详细说明

      想用sphinxql只得到结果数。跟mysql里的count(*)一样 ...

      MYSQL教程网5282019-12-17
    • MysqlMysql 开启Federated引擎的方法

      Mysql 开启Federated引擎的方法

      FEDERATED是其中一个专门针对远程数据库的实现。一般情况下在本地数据库中建表会在数据库目录中生成相应的表定义文件，并同时生成相应的数据文件 ...

      MYSQL教程网5802019-12-14
    • MysqlMySQL数据库安全设置与注意事项小结

      MySQL数据库安全设置与注意事项小结

      现在很多朋友使用mysql数据库，为了安全考虑我们就需要考虑到mysql的安全问题，例如需要将mysql以普通用户权限运行，就算出问题了有了root也不能控制系统...

      MYSQL教程网4352020-01-08
    • MysqlMysql实验之使用explain分析索引的走向

      Mysql实验之使用explain分析索引的走向

      索引是mysql的必须要掌握的技能，同时也是提供mysql查询效率的手段。通过以下的一个实验可以理解？mysql的索引规则，同时也可以不断的来优化sql语句...

      crelaber3822020-08-24
    • MysqlCentos7下安装和配置MySQL5.7.20的详细教程

      Centos7下安装和配置MySQL5.7.20的详细教程

      这篇文章主要介绍了Linux（CentOS7）下安装和配置MySQL5.7.20详细教程，本文通过图文并茂的形式给大家介绍的非常详细，对大家的学习或工作具有一定的参考...

      女妖精6492021-01-18
    • MysqlSQL查询语句优化的实用方法总结

      SQL查询语句优化的实用方法总结

      下面小编就为大家带来一篇SQL查询语句优化的实用方法总结。小编觉得挺不错的，现在就分享给大家，也给大家做个参考。一起跟随小编过来看看吧 ...

      数据库之家2962020-07-05
    • MysqlMysql数据库命令大全

      Mysql数据库命令大全

      mysql命令大家经常会用到，但是很少有朋友整理吧，最近项目不多，抽个时间把mysql数据库命令总结给大家，需要的朋友可以参考下 ...

      宁静.致远3012020-05-19
    • Mysqlmysql中count(), group by, order by使用详解

      mysql中count(), group by, order by使用详解

      mysql中order by 排序查询、asc升序、desc降序，group by 分组查询、having 只能用于group by子句、作用于组内，having条件子句可以直接跟函数表达式。使用group by 子...

      linux_c_coding_man1832020-07-29
    最近更新
    编辑推荐
    阅读排行
    热门标签
    150 　 1044 　 1062 　 1053 　 1045 　 1449 　 1005 　 1819 　 1290 　 2013 　 1862 　 1864 　 2006 　 2003 　 1406 　 1615 　 10048 　 1577 　 1786 　 1215 　 1146 　 2002 　 1366 　 10061 　 1067 　 1135 　 1130 　 1698 　 1175 　 28000 　
    © 2019-2021 服务器之家(www.zzvips.com) 版权所有关于我们联系我们版权申明网站地图