首页 > 数据库 >SQL优化系列之 in与range 查询

SQL优化系列之 in与range 查询

时间：2023-08-01 12:12:46浏览次数：45  
标签：index dive 查询 索引 range limit SQL eq

《高性能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.

换言之，

  1. eq_range_index_dive_limit = 0 只能使用index dive
  2. 0 < eq_range_index_dive_limit <= N 使用index statistics
  3. 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如下：

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

索引如下：

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)

看下执行计划：

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最后的排序肯定会生成一个临时结果集，然后再结果集里面完成排序，而不是直接在索引中直接完成排序动作，于是我们尝试增加了一条索引。

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的值。

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来一看究竟。

{
  "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计算方式，得到更准确的执行计划呢？

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结果如下

{
  "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

+----------------------+----------+
| 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

+----------------------+----------+
| 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

set optimizer_trace='enabled=on';
select * from information_schema.optimizer_trace\G

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

如何使用profile

set profiling=ON;
执行sql;
show profiles;
show profile for query 2;
show profile block io,cpu for query 2;

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

转载自杨奇龙博客

标签：index,dive,查询,索引,range,limit,SQL,eq
From： https://www.cnblogs.com/lovezhr/p/17596110.html

相关文章

  • 导入mysql 乱码问题及 Linux 中的文件格式转换
    问题下载了一个单词sql文件，导入mysql报错，查看文件类型:%fileenglish_word.sqlenglish_word.sql:Non-ISOextended-ASCIItext与另一个导入成功的文件对比，发现格式不一样：%fileenglish-root.sqlenglish-root.sql:UTF-8Unicodetext,withverylonglines,withnoli......
  • MySQL8压缩包安装教程
    解压缩包配置环境变量初始化mysqld--initialize-insecure安装服务mysqldinstallMySQL8移除服务mysqldremoveMySQL8启动服务netstartMySQL8修改密码切换数据库usemysql;修改root用户的密码alteruser'root'@localhostidentifiedby'mysql';刷新权限,一般......
  • liunx 环境 mysql5.6安装
    1安装包下载mysql5.6下载地址：http://dev.mysql.com/downloads/mysql/ 这里选择Linux版本:使用Navicat管理远程Linux服务器上的MySQL数据库 http://www.linuxidc.com/Linux/2011-09/42285.htm ftp://mirror.switch.ch/mirror/mysql/Downloads/MySQL-5.6/2mysql的安装从官网下载......
  • MySQL中动态SQL的解决方法：预处理语句
    动态SQL是一种很好的特性，允许开发人员在运行时动态构建和执行SQL语句。虽然MySQL缺乏对动态SQL的内置支持，但本文介绍了使用预处理语句(preparedstatements)的变通方法。将探讨如何利用预处理语句实现动态查询执行、参数化查询以及动态表和列查询。 了解预处理语句(preparedst......
  • SAS 编程技巧 - PROC SQL（二）
    上一节中，我们介绍了如何使用SQL创建和删除数据集、视图和索引。这一节我们介绍如何使用SQL修改数据集的结构和更新数据集中的数据。修改数据集结构使用ALTERTABLE可以修改数据集的结构，包括增加、删除变量、修改变量属性，以及对数据完整性约束（integrityconstraints）的操作......
  • docker 不适合MySQL
    近几年Docker非常的火热，各位开发者恨不得把所有的应用、软件都部署在Docker容器中，但是您确定也要把数据库也部署的容器中吗？这个问题不是子虚乌有，因为在网上能够找到很多各种操作手册和视频教程，这里整理了一些数据库不适合容器化的原因供大家参考，同时也希望大家在使用时能够谨慎一......
  • MySQL加锁逻辑与死锁
    RC级别:create table t1(id int primary key, name varchar(30));insert into t1 values(1, 'a'),(4, 'c'),(7, 'b'),(10, 'a'),(20, 'd'),(30, 'b');commit;案例一--sess1           --sess2begin;              ......
  • Java面试题 P28：数据库篇：MySql篇-MySql优化-索引-什么是索引？索引的底层数据结构是什么？
    什么是索引：索引（index）是帮助MySql高效获取数据的数据结构（有序）。在数据之外，数据库还维护着满足特定查找算法的数据结构（B+树），这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法，这种数据结构就是索引。 ......
  • PHP+sql3实现评论区功能
    首先，在这之前，先知道，我是把这个评论区分为，“提问”以及“回答”两部分。 难点一、事件委托！使得按钮生效我遇到一个问题就是，每次通过PHP，拿到数据库的数据，我把它的HTML拼接好，拼接成字符串再返回到xhr.responseText时，循环输出的这些“提问”，最右边的“回复”按钮用不了，这里我最......
  • 查看mysql有无启动日志
    showvariableslike'log_%'这些参数代表着MySQL的日志相关配置，对每个配置进行介绍如下：1.`log_bin`:指定二进制日志文件的开启状态。2.`log_bin_basename`:指定二进制日志文件名的前缀，MySQL会在其后面自动增加数字序列作为文件名。3.`log_bin_index`:指定MySQL的二进制......

赞助商

阅读排行

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

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

Copyright © 2020-2023 IPS99 版权所有 IPS99