MySQL 索引优化

2018-08-14 本文已影响0人杨仕杰

一. 最左前缀原理

以 MySQL 官方示例数据库 employees 的 titles 表的 <emp_no, from_date> 主键索引来进行说明。

(一). 全值匹配

当按照索引中所有列进行精确匹配 ("=" 或 "IN" 匹配) 时，索引可以被用到。理论上索引对顺序是敏感的，但是 MySQL 查询优化器会自动调整 WHERE 子句的条件顺序以使用适合的索引。

EXPLAIN SELECT * 
FROM employees.titles 
WHERE emp_no='10001' AND title='Senior Engineer' AND from_date='1986-06-26'\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: titles
         type: const
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 59
          ref: const,const,const
         rows: 1
        Extra: 
1 row in set (0.00 sec)

(二). 最左前缀匹配

当查询条件精确匹配索引的左边连续一个或几个列时，索引可以被用到，但是只能用到一部分，即条件所组成的最左前缀。

EXPLAIN SELECT * FROM employees.titles WHERE emp_no='10001'\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: titles
         type: ref
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: const
         rows: 1
        Extra: 
1 row in set (0.00 sec)

(三). 全值匹配，但是中间某个条件未提供

此时索引使用情况和 "最左前缀匹配" 相同，因为 title 未提供，所以查询只用到了索引的第一列，而后面的 from_date 虽然也在索引中，但是由于 title 不存在而无法和左前缀连接，因此需要对结果进行扫描过滤 from_date。

EXPLAIN SELECT * 
FROM employees.titles WHERE emp_no='10001' AND from_date='1986-06-26'\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: titles
         type: ref
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: const
         rows: 1
        Extra: Using where
1 row in set (0.00 sec

如果想让 from_date 列也使用索引而不是使用 WHERE 过滤，可以增加一个辅助索引 <emp_no, from_date>。除此之外，还可以使用一种被称之为 "隔离列" 的优化方法，将 emp_no 与 from_date 之间的 "坑" 填上。

SELECT DISTINCT(title) FROM employees.titles;
+--------------------+
| title              |
+--------------------+
| Senior Engineer    |
| Staff              |
| Engineer           |
| Senior Staff       |
| Assistant Engineer |
| Technique Leader   |
| Manager            |
+--------------------+
7 rows in set (0.20 sec)

EXPLAIN SELECT * 
FROM employees.titles 
WHERE emp_no='10001' 
  AND title IN (
    'Senior Engineer', 
    'Staff', 
    'Engineer', 
    'Senior Staff', 
    'Assistant Engineer', 
    'Technique Leader', 
    'Manager') 
  AND from_date='1986-06-26'\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: titles
         type: range
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 59
          ref: NULL
         rows: 7
        Extra: Using where
1 row in set (0.00 sec)

SHOW PROFILES\G
*************************** 1. row ***************************
Query_ID: 1
Duration: 0.00032611
   Query: SELECT * FROM employees.titles 
          WHERE emp_no='10001' AND from_date='1986-06-26'
*************************** 2. row ***************************
Query_ID: 2
Duration: 0.00031092
   Query: SELECT * FROM employees.titles
          WHERE emp_no='10001'
            AND title IN (
                'Senior Engineer', 
                'Staff', 
                'Engineer', 
                'Senior Staff', 
                'Assistant Engineer', 
                'Technique Leader',
                 'Manager')
            AND from_date='1986-06-26'
2 rows in set (0.00 sec)

但只有在这种成为 "坑" 的列值比较少的情况下，才可以考虑用 "IN"来填补这个 "坑" 从而形成最左前缀。

(四). 匹配某列的前缀字符串

此时可以用到索引。如果如果通配符 % 不出现在开头，则可以用到索引，但根据具体情况不同可能只会用其中一个前缀。

EXPLAIN SELECT * 
FROM employees.titles WHERE emp_no='10001' AND title LIKE 'Senior%'\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: titles
         type: range
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 56
          ref: NULL
         rows: 1
        Extra: Using where
1 row in set (0.00 sec)

(五). 范围查询

范围列可以用到索引 (必须是最左前缀)，但是范围列后面的列无法用到索引。索引最多用于一个范围列，因此如果查询条件中有两个范围列则无法全用到索引。

EXPLAIN SELECT * 
FROM employees.titles WHERE emp_no < '10010' and title='Senior Engineer'\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: titles
         type: range
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: NULL
         rows: 14
        Extra: Using where
1 row in set (0.00 sec)

MySQL 有一个非常有意思的地方：仅用 EXPLAIN 可能无法区分范围索引和多值匹配，因为在 type 中这两者都显示为 range。同时用了 "between" 并不意味着就是范围查询。

下面的查询中，看起来是用了两个范围查询，但作用于 emp_no 上的 "BETWEEN" 实际上相当于 "IN"，也就是说 emp_no 实际是多值精确匹配。可以看到这个查询用到了索引全部三个列。因此在 MySQL 中要谨慎地区分多值匹配和范围匹配，否则会对 MySQ L的行为产生困惑。

EXPLAIN SELECT * 
FROM employees.titles
WHERE emp_no BETWEEN '10001' AND '10010'
AND title='Senior Engineer'
AND from_date BETWEEN '1986-01-01' AND '1986-12-31'\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: titles
         type: range
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 59
          ref: NULL
         rows: 15
        Extra: Using where
1 row in set (0.00 sec)

(六). 查询条件中含有函数或表达式

如果查询条件中含有函数或表达式，则 MySQL 不会为这列使用索引。

EXPLAIN SELECT * 
FROM employees.titles WHERE emp_no='10001' AND left(title, 6)='Senior'\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: titles
         type: ref
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: const
         rows: 1
        Extra: Using where
1 row in set (0.00 sec)

二. 索引选择性

索引虽然加快了查询速度，但也是有代价的。索引文件本身要消耗存储空间，同时索引会增加插入、删除和修改记录时的开销。另外 MySQL 在运行时也要消耗资源维护索引，因此索引并不是越多越好。

一般 3 种情况下不建议使用索引：

第一种情况是表记录比较少。没必要建索引，让查询做全表扫描就好。根据记录数不超过 2000 可以考虑不建索引，超过 2000 条可以酌情考虑索引
第二种情况是表记录过多，建立和使用索引的代价将会增加。这种情况下，需要一种技术可以直接区分出查询需要的一组数据，而不是一条一条记录地匹配。可以使用分区技术
最后一种情况是索引的选择性较低。所谓索引的选择性是指不重复的索引值与表记录数的比值。显然选择性的取值范围为(0, 1]，选择性越高的索引价值越大，这是由 B+Tree 的性质决定的

三. 前缀索引

前缀索引是用列的前缀代替整个列作为索引 key，当前缀长度合适时，可以做到既使得前缀索引的选择性接近全列索引，同时因为索引 key 变短而减少了索引文件的大小和维护开销。

对于 BLOB、TEXT 或者很长的 VARCHAR 的列，必须使用前缀索引。MySQL 不允许索引这些列的完整长度。

前缀索引兼顾索引大小和查询速度，缺点是不能用于 ORDER BY 和 GROUP BY 操作，也不能用于索引覆盖扫描 (即当索引本身包含查询所需全部数据时，不再访问数据文件本身)。

EXPLAIN SELECT * 
FROM employees.employees WHERE first_name='Eric' AND last_name='Anido'\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: employees
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 300252
        Extra: Using where

SELECT count(DISTINCT(first_name))/count(*) AS Selectivity FROM employees.employees;
+-------------+
| Selectivity |
+-------------+
|      0.0042 |
+-------------+
1 row in set (0.13 sec)

SELECT count(DISTINCT(last_name))/count(*) AS Selectivity FROM employees.employees;
+-------------+
| Selectivity |
+-------------+
|      0.0055 |
+-------------+

SELECT count(DISTINCT(concat(first_name, last_name)))/count(*) AS Selectivity 
FROM employees.employees;
+-------------+
| Selectivity |
+-------------+
|      0.9313 |
+-------------+
1 row in set (0.36 sec)

SELECT count(DISTINCT(concat(first_name, left(last_name, 4))))/count(*) 
  AS Selectivity 
FROM employees.employees;
+-------------+
| Selectivity |
+-------------+
|      0.9007 |
+-------------+
1 row in set (0.36 sec)

ALTER TABLE employees.employees 
  ADD INDEX `first_name_last_name4` (first_name, last_name(4));

EXPLAIN SELECT * 
FROM employees.employees WHERE first_name='Eric' AND last_name='Anido'\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: employees
         type: ref
possible_keys: first_name_last_name4
          key: first_name_last_name4
      key_len: 22
          ref: const,const
         rows: 1
        Extra: Using index condition; Using where
1 row in set (0.00 sec)

SHOW PROFILES\G
*************************** 1. row ***************************
Query_ID: 1
Duration: 0.13175585
   Query: SELECT * 
          FROM employees.employees WHERE first_name='Eric' AND last_name='Anido'
*************************** 15. row ***************************
Query_ID: 2
Duration: 0.00034243
   Query: SELECT * 
          FROM employees.employees WHERE first_name='Eric' AND last_name='Anido'

四. 覆盖索引

如果一个索引包含 (或者覆盖) 所有要查询的字段的值，就称其为 "覆盖索引"。当发起一个被索引覆盖的查询时，在 EXPLAIN 的 Extra 列可以看到 "Using index" 的信息。

覆盖索引具有如下优点：

索引条目通常远小于数据行大小，所以如果只需要读取索引，那么 MySQL 就会极大的减少数据访问量。这对缓存的负载非常重要，因为这种情况下响应时间大部分花在数据的拷贝上。覆盖索引对 I/O 密集型的应用同样有帮助，因为索引比数据更小，更容易全部放在内存中
因为索引是按照列值顺序存储的 (至少在单页内是如此)，所以对于 I/O 密集型的范围查询会比随机从磁盘读取每一行数据的 I/O 要少得多。对于某些存储引擎，例如 MyISAM，甚至可以通过 OPTIMIZE 命令使得索引完全顺序排列，这让简单的范围查询能使用完全顺序的索引访问
一些存储引擎如 MyISAM 在内存中只缓存索引，数据则依赖于操作系统来缓存，因此要访问数据需要一次系统调用。这可能会导致严重的性能问题，尤其是那些系统调用占用数据访问中的最大开销的场景
由于 InnoDB 的聚簇索引，覆盖索引对 InnoDB 表特别有用。InnoDB 的二级索引在叶子节点保存了行的主键值，所以如果二级主键能够覆盖查询，则可以避免对主键索引的二次查询

索引覆盖查询有很多陷阱可能导致无法实现优化。MySQL 查询优化器会在执行查询前判断是否有一个索引能进行覆盖。假设所有覆盖了 WHERE 条件中的字段，但不是整个查询设计的字段。如果条件为假，MySQL 5.5 和更早的版本也总是会回表获取数据行，尽管并不需要这一行且最终会被过滤掉。

在大多数存储引擎中，覆盖索引只能覆盖那些只访问索引中部分列的查询。不过可以更进一步优化 InnoDB。InnoDB 的二级索引的叶子节点都包含了主键的值，这意味着 InnoDB 的二级索可以有效的利用这些 "额外" 的主键列来覆盖查询。

五. 多列索引

在多个列上建立独立的单列索引在大部分情况下并不能提高 MySQL 的查询性能。MySQL5.0 和更新版本引入了 "索引合并" 策略，一定程度上可以使用表上的多个单列索引来定位指定的行。查询能够同时使用多个单列索引进行扫描，并将结果进行合并。这种算法有三个变种：OR 条件的联合、AND 条件的相交、组合前两种情况的联合及相交。

索引合并策略有时候是一种优化，但更多的时候说明了表上的索引建的很糟糕：

当出现服务器对多个索引做相交操作时，通常意味着需要一个包含所有相关列的多列索引，而不是多个独立的单列索引
当出现服务器对多个索引做联合操作时，通常需要耗费大量的 CPU 和内存资源在算法的缓存、排序和合并操作上。特别是当其中有些索引的选择性不高，需要合并扫描返回的大量数据的时候
优化器不会把这些计算到 "查询成本" 中，优化器只关心随机页面读取。这会使得查询成本被低估

如果在 EXPLAIN 中看到有索引合并，应该好好检查下查询和表的结构是不是已经是最优的。也可以通过参数 optimizer_switch 来关闭所有合并功能。同时也可以使用 IGNORE INDEX 提示让优化器忽略掉某些索引。

五. 索引顺序

索引列的正确顺序依赖于使用该索引的查询，并且同时需要考虑如何更好地满足排序和分组的需要。在一个包含多列的索引中，索引列的顺序意味着所有首先按照最左列进行排序，其次是第二列，等等。索引可以按照升序或降序进行扫描，以满足精确符合列顺序的 ORDER BY、GROUP BY 和 DISTINCT 等子句的查询要求。

当不需要考虑排序和分组时，将选择性最高的列放在前面通常是很好的。这时候索引的作用只是用于优化 WHERE 条件的查询。在这种情况下，这样设计的索引确实能够最快地过滤出需要的行，对于在 WHERE 子句中只使用了索引部分前缀列的查询来说选择性也更高。然而，性能并不只是依赖于所有索引列的选择性，也和查询条件的具体值有关，也就是和值的分布有关。可能需要根据那些运行频率最高的查询来调整索引列的顺序，让这种情况下索引的选择性最高。

六. 索引排序

MySQL 有两种方式可以生成有序的结果：通过排序操作、通过索引顺序扫描。如果 EXPLAIN 的 type 列的值为 "index"，则说明 MySQL 使用了索引扫描来做排序。

扫描索引本身是很快的，因为只需从一条索引记录移动到紧接着的下一条记录。但如果索引不能覆盖查询所需的全部列，那就不得不扫描一条索引记录都回表查询一次对应的行。这基本上都是随机 I/O 操作，因此按索引顺序读取数据的速度通常要比顺序地全表扫描慢，尤其是在 I/O 密集型的工作负载时。

只有当索引的列顺序和 ORDER BY 子句的顺序完全一致，并且所有列的排序方向都一样时，MySQL 才能够使用索引来对结果进行排序。如果查询需要关联多张表，则只有当 ORDER BY 子句引用的字段全部为第一个表时，才能使用索引做排序。ORDER BY 子句和查找型查询的限制是一样的：需要满足索引的最左前缀的要求；否则，MySQL 都需要执行排序操作，而无法利用索引排序。

有一种情况下的 ORDER BY 子句可以不满足索引的最左前缀的要求，就是前导列为常量的时候。如果 WHERE 子句或者 JOIN 子句中对这些列指定了常量，就可以 "弥补" 索引的不足。

CREATE TABLE rental(
    PRIMARY KEY (rental_id),
    UNIQUE KEY rental_data (rental_data, inventory_id, customer_id)
);

SELECT rental_id, staff_id 
FROM rental
WHERE rental_data = '2005-05-25'
ORDER BY inventory_id, customer_id

六. 哈希索引

如果存储引擎不支持哈希索引，可以在 B-Tree 基础上创建一个伪哈希索引。这和真正的哈希索引不是一回事，因为还是使用 B-Tree 进行查找，但它使用哈希值而不是键值进行索引查找。需要做的就是在查询的 WHERE 子句中手动指定哈希函数。这样实现的缺陷是需要维护哈希值 (可以手动维护，也可以用触发器实现)。

-- 创建如下表
CREATE TABLE pseudohash(
    id int unsigned NOT NULL auto_increment,
    url varchar(255) NOT NULL,
    url_crc int unsigned NOT NULL DEFAULT 0,
    PRIMARY KEY(id)
);

-- 创建触发器 (先临时修改一下语句分隔符，这样可以在触发器定义中使用分号)
DELIMITRE //

CREATE TRIGGER pseudohash_crc_ins BEFORE INSERT ON pseudohash FOR EACH ROW BEGIN
SET NEW.url_crc=crc32(NEW.url);
END;
//

CREATE TRIGGER pseudohash_crc_upd BEFORE UPDATE ON pseudohash FOR EACH ROW BEGIN
SET NEW.url_crc=crc32(NEW.url);
END;
//

DELIMITER ;

如果采用自定义哈希索引的方式，不要使用 SHA1() 和 MD5() 作为哈希函数。因为这两个函数计算出来的哈希值是非常长的字符串，会浪费大量空间。如果数据表非常大，CRC32() 会出现大量的哈希冲突，则可以考虑自己实现一个简单的 64 位哈希函数。这个自定义的函数要返回整数，而不是字符串。一个简单的办法可以使用 MD5() 函数返回值的一部分来作为自定义函数。

当使用哈希索引进行查询时，要避免哈希冲突的问题，必须在 WHERE 条件中带入哈希值和对应列值。如果不是想查询具体值，例如只是统计记录数则可以不带入列值，直接使用 CRC32() 的哈希值查询即可。

五. 主键选择

使用 InnoDB 存储引擎时，如果没有特别的需要，请永远使用一个与业务无关的自增字段作为主键。从数据库索引优化角度看，使用 InnoDB 引擎而不使用自增主键绝对是一个糟糕的主意。

InnoDB 使用聚簇索引，数据记录被存放于主键索引的叶子节点上。这要求同一个叶子节点内的各条数据记录按主键顺序存放。每当有一条新的记录插入时，MySQL 会根据其主键将其插入适当的节点和位置。如果页面达到装载因子 (默认为15/16)，则开辟一个新的页 (节点)。

如果表使用自增主键，那么每次插入新的记录，记录就会顺序添加到当前索引节点的后续位置，当一页写满，就会自动开辟一个新的页。这样就会形成一个紧凑的索引结构，近似顺序填满。每次插入时也不需要移动已有数据，因此效率很高，也不会增加很多开销在维护索引上。

如果使用非自增主键，每次插入主键的值近似于随机，因此新增的纪录都要被插到现有索引页得中间某个位置。此时 MySQL 不得不为了将新记录插到合适位置而移动数据，甚至目标页可能已经被回写到磁盘上而从缓存中清掉。此时又要从磁盘上读回来，这增加了很多开销。同时频繁的移动、分页操作造成了大量的碎片，使得索引结构不够紧凑，不得不通过 OPTIMIZE TABLE 来重建表并优化填充页面。