MySQL SQL优化之‘%’

设计索引的主要目的就是帮助我们快速获取查询结果，而以%开头的like查询则不能够使用B-Tree索引。
考虑到innodb的表都是聚簇表（类似于oracle中的索引组织表），且二级索引叶节点中记录的结构为（索引字段->主键字段），我们可以通过改写sql（mysql优化器比较笨，需要给它足够的提示）采取一种轻量级的方式代替全表扫：
使用索引全扫描找到主键，再根据主键回表获取数据的方法。
这种方式的速度优势在单行记录数据量较大、表中记录较多的情况下体现的尤为明显，因为此时索引全扫描带来的IO开销相对于全表扫会小得多。

纸上得来终觉浅，绝知此事要躬行：
创建测试表test，表上有自增主键primary(id)和二级索引idx_name1(name1)，表中有500万条数据。

mysql> desc test;
+--------+-------------+------+-----+---------+----------------+
| Field  | Type        | Null | Key | Default | Extra          |
+--------+-------------+------+-----+---------+----------------+
| id     | int(11)     | NO   | PRI | NULL    | auto_increment |
| name1  | varchar(20) | YES  | MUL | NULL    |                |
| name2  | varchar(20) | YES  |     | NULL    |                |
| name3  | varchar(20) | YES  |     | NULL    |                |
| name4  | varchar(20) | YES  |     | NULL    |                |
| name5  | varchar(20) | YES  |     | NULL    |                |
| name6  | varchar(20) | YES  |     | NULL    |                |
| name7  | varchar(20) | YES  |     | NULL    |                |
| name8  | varchar(20) | YES  |     | NULL    |                |
| name9  | varchar(20) | YES  |     | NULL    |                |
| name10 | varchar(20) | YES  |     | NULL    |                |
+--------+-------------+------+-----+---------+----------------+
11 rows in set (0.01 sec)

mysql> show index from test\G
*************************** 1. row ***************************
        Table: test
   Non_unique: 0
     Key_name: PRIMARY
 Seq_in_index: 1
  Column_name: id
    Collation: A
  Cardinality: 4829778
     Sub_part: NULL
       Packed: NULL
         Null:
   Index_type: BTREE
      Comment:
Index_comment:
*************************** 2. row ***************************
        Table: test
   Non_unique: 1
     Key_name: idx_name1
 Seq_in_index: 1
  Column_name: name1
    Collation: A
  Cardinality: 2414889
     Sub_part: NULL
       Packed: NULL
         Null: YES
   Index_type: BTREE
      Comment:
Index_comment:
2 rows in set (0.00 sec)

mysql> select count(*) from test;
+----------+
| count(*) |
+----------+
|  5000000 |
+----------+
1 row in set (1.59 sec)

基于name1进行like查询，耗时11.13s，从执行计划看，sql在执行时走的是全表扫描(type: ALL)：

mysql>  select * from test where name1 like ‘%O4JljqZw%‘\G
*************************** 1. row ***************************
    id: 1167352
 name1: BO4JljqZws
 name2: BrfLU7J69j
 name3: XFikCVEilI
 name4: lr0yz3qMsO
 name5: vUUDghq8dx
 name6: RvQvSHHg4p
 name7: ESiDbQuK8f
 name8: GugFnLtYe8
 name9: OuPwY8BsiY
name10: O0oNGPX9IW
1 row in set (11.13 sec)

mysql> explain select * from test where name1 like ‘%O4JljqZw%‘\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: test
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 4829778
        Extra: Using where
1 row in set (0.00 sec)

将sql改写为‘select a. from test a,(select id from test where name1 like ‘%O4JljqZw%‘) b where a.id=b.id;’
提示优化器在子查询中使用二级索引idx_name1获取id：

mysql> select a.* from test a,(select id from test where name1 like ‘%O4JljqZw%‘) b where a.id=b.id\G
*************************** 1. row ***************************
    id: 1167352
 name1: BO4JljqZws
 name2: BrfLU7J69j
 name3: XFikCVEilI
 name4: lr0yz3qMsO
 name5: vUUDghq8dx
 name6: RvQvSHHg4p
 name7: ESiDbQuK8f
 name8: GugFnLtYe8
 name9: OuPwY8BsiY
name10: O0oNGPX9IW
1 row in set (2.46 sec)

mysql> explain select a.* from test a,(select id from test where name1 like ‘%O4JljqZw%‘) b where a.id=b.id\G
*************************** 1. row ***************************
           id: 1
  select_type: PRIMARY
        table: <derived2>
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 4829778
        Extra: NULL
*************************** 2. row ***************************
           id: 1
  select_type: PRIMARY
        table: a
         type: eq_ref
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: b.id
         rows: 1
        Extra: NULL
*************************** 3. row ***************************
           id: 2
  select_type: DERIVED
        table: test
         type: index
possible_keys: NULL
          key: idx_name1
      key_len: 63
          ref: NULL
         rows: 4829778
        Extra: Using where; Using index
3 rows in set (0.00 sec)

改写后的sql执行时间缩短至2.46s，效率提升了近4倍！
执行计划分析如下:
step 1：mysql先对二级索引idx_name1进行覆盖扫描取出符合条件的id(Using where; Using index)
step 2：对子step 1衍生出来的结果集table: <derived2>进行全表扫，获取id（本案例中只有一个id符合条件）
step 3：最后根据step 2中的id使用主键回表获取数据(type: eq_ref,key: PRIMARY )

总结：
在表中每条记录的数据量较大时，通过这种方法改写后的sql效率会有明显提升。
本实验中每条记录的数据量还很小，如果每条记录的数据量进一步加大，改写后sql的执行效率会有数量级的提升，大家可以自行验证~

原文地址：http://blog.51cto.com/13476134/2126048

时间： 2024-08-02 00:43:19

MySQL SQL优化之‘%’的相关文章

mysql sql优化

前言 有人反馈之前几篇文章过于理论缺少实际操作细节.这篇文章就多一些可操作性的内容吧. 注:这篇文章是以 MySQL 为背景,非常多内容同一时候适用于其它关系型数据库,须要有一些索引知识为基础. 优化目标 1.降低 IO 次数 IO永远是数据库最easy瓶颈的地方,这是由数据库的职责所决定的,大部分数据库操作中超过90%的时间都是 IO 操作所占用的,降低 IO 次数是 SQL 优化中须要第一优先考虑.当然,也是收效最明显的优化手段. 2.减少 CPU 计算 除了 IO 瓶颈之外,SQL优化中须

mysql sql优化及注意事项

sql优化分析 通过slow_log等方式可以捕获慢查询sql,然后就是减少其对io和cpu的使用(不合理的索引.不必要的数据访问和排序)当我们面对具体的sql时,首先查看其执行计划A.看其是否使用索引B.查看其查询的记录数C.确定索引的代价是否过高D.是否可以使用复合索引E.是否有“using temporary”F.是否有“using filesort” 创建高效索引 mysql的innodb有自己特殊的聚集索引(数据是按聚集索引的顺序存储的并和索引存储在一起),索引访问效率较高,次要索引是

18.Mysql SQL优化

18.SQL优化18.1 优化SQL语句的一般步骤 18.1.1 通过show status命令了解各种SQL的执行频率show [session|global] status; -- 查看服务器状态信息show session status; -- 查看session(当前连接)级别的服务器状态信息,默认session级别show global status; -- 查看global(数据库启动至今)级别的服务器状态信息show status like 'Com_%'; -- 查看当前sess

Mysql——SQL优化-统计某种类型的个数

有时我们想统计某种类型有多少个,会用这个SQL.全表扫描之余,还要filesort,耗时1.34秒. mysql> select country,count(*) from t1 group by country; +---------+----------+ | country | count(*) | +---------+----------+ | NULL | 32 | | africa | 524288 | | america | 524288 | | china | 524288 |

mysql sql优化之expain

explain显示了mysql如何使用索引来处理select语句以及连接表.可以帮助选择更好的索引和写出更优化的查询语句. 1. id SELECT识别符.这是SELECT查询序列号.查询序号即为sql语句执行的顺序 2.select_type select类型,它有以下几种值 2.1 simple 它表示简单的select,没有union和子查询 2.2 primary 最外面的select,在有子查询的语句中,最外面的select查询就是primary,上图中就是这样 2.3 union  

(MYSQL)SQL优化工具 - SQLAdvisor 安装使用详解

一.SQLAdvisor简介 SQLAdvisor是由美团点评公司技术工程部DBA团队(北京)开发维护的一个分析SQL给出索引优化建议的工具.它基于MySQL原生态词法解析,结合分析SQL中的where条件.聚合条件.多表Join关系 给出索引优化建议.目前SQLAdvisor在美团点评广泛应用,包括美团支付.酒店旅游.外卖.团购等产品线,公司内部对SQLAdvisor的开发全面转到github上,开源和内部使用保持一致. 二.SQLAdvisor安装 1.拉取最新代码 git clone ht

MySQL SQL优化之in与range查询

本文来自:http://hidba.ga/2014/09/24/in-and-range/ 首先我们来说下in()这种方式的查询.在<高性能MySQL>里面提及用in这种方式可以有效的替代一定的range查询,提升查询效率,因为在一条索引里面,range字段后面的部分是不生效的.使用in这种方式其实MySQL优化器是转化成了n*m种组合方式来进行查询,最终将返回值合并,有点类似union但是更高效.同时它存在这一些问题: 老版本的MySQL在IN()组合条件过多的时候会发生很多问题.查询优化可

MySQL SQL优化之字符串索引隐式转换

之前有用户很不解:SQL语句非常简单,就是select * from test_1 where user_id=1 这种类型,而且user_id上已经建立索引了,怎么还是查询很慢? test_1的表结构: CREATE TABLE `test_1` ( `id` int(11) NOT NULL AUTO_INCREMENT, `user_id` varchar(30) NOT NULL, `name` varchar(30) DEFAULT NULL, PRIMARY KEY (`id`),

MySQL SQL优化-让你脑洞大开

由于分库分表的原因,和开发规定了不能使用 表表JOIN 语句.因此,我们要将 JOIN 语句的转化成使用 IN 来做.如现在有 表 A(a_id, c_a)c_a有普通索引,表 B(b_id, c_a) 这两个表要关联, 应该转化为以下步骤处理: 先查询B中的 a_id SELECT c_a FROM B WHERE xxx; 使用 IN 查询 A 表 SELECT a_id, ... FROM A WHERE c_a IN(在 1 中查出来的 c_a) 场景 现在表的数据量有 800万. 一般