Mysql：根据查询语句来建立最佳索引【翻译】

Mysql：根据查询语句来建立最佳索引

译文仅供参考，很多不是原句照搬

The Problem问题

你有一个select语句并且想为它建立一个最佳的索引。这篇文章就像是一本如何实现这个目标的“cookbook”。
本cookbook将包含：

一个很简单的算法适用于很多简单的select查询，并且同样适用一些高级查询
很多算法样例，加上一些题外话，例外案例和变题
最后会有一长串的其他案例

Algorithm算法

下面是一个达到创建索引的方法，给定一个select，按照下面给出的步骤，将所有的列按照顺序放进索引中，当你遍历完下面给出的步骤时，通常你将得到一个“最佳”索引。

给定一个由一堆AND连接的where语句：所有的列，无论是什么顺序，都在跟一个参数比较并且没有藏在一个方法里
你有好几个机会来添加索引，哪个先满足条件就优先安排哪个为索引
2a. 有某列使用了range – BETWEEN, >, LIKE 没有前置通配符（给索引
2b. 所有group_by的列，按照顺序（给索引
3c. 所有order_by的列，按照顺序（给索引

Digression题外话

这篇文章假设你已经知道很多创建索引背后的基本逻辑，下面回顾几个关键点加深一下印象。
通常，所有MySQL的索引都是B树结构
B树在这些方面会很有效率

给定一个key，找到对应的row(s)
“Range scans（范围查找）” – 指从一个值开始依次重复查找下一行或者上一行

PRIMARY KEY 主键
SECONDARY KEY 副键
UNIQUE KEY 唯一键
INDEX 索引

A PRIMARY KEY is a UNIQUE KEY; a UNIQUE KEY is an INDEX. (KEY == INDEX.)

InnoDB 将PRIMARY KEY的数据聚集在一起，给定PRIMARY KEY的值，在扫描了整个B树后找到了索引的入口，你将在那获得目标行下所有列的数据。secondary key (any UNIQUE or INDEX other than the PK) 在InnoDB里先是扫描B树拿到secondary key本身，得到的是PK的拷贝，然后你再去扫描PK从而找到目标行。

每一个InnoDB 的table都有一个PRIMARY KEY。如果你不指定，那就会默认一个。最好是能明确给出PK。
补充一下：MyISAM则完全不同，所有的索引（包括pk）都隶属于不同的B树，这类B树的叶子节点都有一个指针 (usually a byte offset) 指向数据集。

以上所有的讨论都是基于InnoDB的tables，但是大部分陈述也适用于其他引擎。

First, some examples首先，一些举例

假设有一组名字，按last_name排序，然后是first_name. 你肯定见过这样的数组，通常它们还包含了一些其他的信息，比如地址或者是电环号码。假设你想做一次查询。如果你记得我的全名(‘James’ and ‘Rick’), 那么你很容易找到我的（数据）入口。如果你只记得我的last_name(‘James’) 和first_name是从一个“R”字母开始的单词。你可以快速定位到很多包含James的并且找到last_name开头为R的数据。因此你可以专注‘Rick’而忽略掉‘Ronald’。但是，如果你记得我的first_name(‘Rick’),last_name是从‘J’开头。那么你就麻烦了，你得把所有Js的数据都扫描一遍-- Jones, Rick; Johnson, Rick; Jamison, Rick; 等等等等.这样效率就会低很多。

上面的距离转换成语句：

INDEX(last_name, first_name) -- the order of the list.
WHERE last_name = 'James' AND first_name = 'Rick'  -- best case
WHERE last_name = 'James' AND first_name LIKE 'R%' -- pretty good
WHERE last_name LIKE 'J%' AND first_name = 'Rick'  -- pretty bad

下面算法讨论“=”跟“range”的对比的时候可以继续想想这个案例。

Algorithm, Step 1 (WHERE “column = const”)

⚈  WHERE aaa = 123 AND ... -- an INDEX starting with aaa is good.
⚈  WHERE aaa = 123 AND bbb = 456 AND ... -- an INDEX starting with aaa and bbb is good. In this case, it does not matter whether aaa or bbb comes first in the INDEX.
⚈  xxx IS NULL -- this acts like "= const" for this discussion.
⚈  WHERE t1.aa = 123 AND t2.bb = 456 -- You must only consider columns in the current table.

要注意表达式必须是column_name=(constant).
这些表述是不适用于step1的：

DATE(dt) = '...', 
LOWER(s) = '...', 
CAST(s ...) = '...', 
x='...' 
COLLATE...

“column都藏在了function中”。用不到索引。
如果where语句中没有“=”相连接的话，可以移步到step2去寻找你的索引。

Algorithm, Step 2

从2a / 2b / 2c 找到第一条适用的，然后建立索引，然后退出。如果没有任何一条适用，那么你也完成了索引的收集。
在某些情况下，最好的策略是把step1（全是等式连接）和step2c（order by）都用上。

Algorithm, Step 2a (one range)

A “range” shows up as

    ⚈  aaa >= 123 -- any of <, <=, >=, >; but not <>, !=, IS NOT NULL
    ⚈  aaa BETWEEN 22 AND 44
    ⚈  sss LIKE 'blah%' -- but not sss LIKE '%blah'
    ⚈  xxx IS NOT NULL

把做了range查询的column都加入到索引待选里。

如果where语句中还有更多的条件，那么寻找索引也必须停止了。

完整的样例（假设这些语句后没有任何多的片段）

⚈  WHERE aaa >= 123 AND bbb = 1   ⇒ INDEX(bbb, aaa) (WHERE order does not matter; INDEX order does)
⚈  WHERE aaa >= 123   ⇒ INDEX(aaa)
⚈  WHERE aaa >= 123 AND ccc > 'xyz'   ⇒ INDEX(aaa) or INDEX(ccc) (only one range) (See ICP, below)
⚈  WHERE aaa >= 123 ORDER BY aaa   ⇒ INDEX(aaa) -- Bonus: The ORDER BY will use the INDEX.
⚈  WHERE aaa >= 123 ORDER BY aaa   ⇒ INDEX(aaa) DESC -- Same Bonus.

（某些情况下同一列可能会有多个range查询，这样的情况也是适用的）

Algorithm, Step 2b (GROUP BY)

如果有GROUP BY，所有GROUP BY的列都应该被添加（到索引），按照一定的顺序（不知道如果其中一列本身已经是索引会发生什么）
如果需要GROUP BY一个表达式（包括方法调用），那么不适用于添加索引，stop。
完整的样例（假设这些语句后没有任何多的片段）

⚈  WHERE aaa = 123 AND bbb = 1 GROUP BY ccc   ⇒ INDEX(bbb, aaa, ccc) or INDEX(aaa, bbb, ccc) (='s first, in any order; then the GROUP BY)
⚈  WHERE aaa >= 123 GROUP BY xxx   ⇒ INDEX(aaa) (You should have stopped with Step 2a)
⚈  GROUP BY x,y   ⇒ INDEX(x,y) (if there is no WHERE)
⚈  WHERE aaa = 123 GROUP BY xxx,(a+b)   ⇒ INDEX(aaa) -- expression in GROUP BY, so no use including even xxx.

如果GROUP BY和ORDER BY 有相同的列和同样的顺序，调整索引进行适配。那样，GROUP BY和ORDER BY 的规则可以同时适用。这样可以避免额外的排序。

Algorithm, Step 2c (ORDER BY)

如果有ORDER BY，所有ORDER BY的列都应该被添加（到索引），按照一定的顺序。
如果ORDER BY里有多个列，并且混合了AES和DESC，不要把这些列添加到索引里；这样做没有任何帮助。（在8.0版本里有一个例外，如果你声明了一个索引是混合了ASE和DESC，那么ORDER BY的列是可以用索引的）
如果不关心结果的顺序的话，将顺序都改成AS或DESC。
如果ORDER BY的是一个表达式（包含方法调用），那么不适用于添加索引，stop。

完整的样例（假设这些语句后没有任何多的片段）

⚈  WHERE aaa = 123 GROUP BY ccc ORDER BY ddd   ⇒ INDEX(aaa, ccc) -- should have stopped with Step 2b
⚈  WHERE aaa = 123 GROUP BY ccc ORDER BY ccc   ⇒ INDEX(aaa, ccc) -- the ccc will be used for both GROUP BY and ORDER BY
⚈  WHERE aaa = 123 ORDER BY xxx ASC, yyy DESC   ⇒ INDEX(aaa) -- mixture of ASC and DESC.

下面这些是特别好的样例。通常情况下索引下的LIMIT都很难有收益，除非已经收集了很多行数据并且进行ORDER BY排序。但是，如果恰好进行ORDER BY的时候，只有（OFFSET + LIMIT）的数据被收集，这些情况下，你新建立的index会得到额外的效果提升。

  ⚈  WHERE aaa = 123 GROUP BY ccc ORDER BY ccc LIMIT 10   ⇒ INDEX(aaa, ccc)
  ⚈  WHERE aaa = 123 ORDER BY ccc LIMIT 10   ⇒ INDEX(aaa, ccc)
  ⚈  ORDER BY ccc LIMIT 10   ⇒ INDEX(ccc)
  ⚈  WHERE ccc > 432 ORDER BY ccc LIMIT 10   ⇒ INDEX(ccc) -- This "range" is compatible with ORDER BY
  ⚈  WHERE ccc < 432 ORDER BY ccc LIMIT 10   ⇒ INDEX(ccc) -- also works

（在没有ORDER BY的情况下做LIMIT好像没有什么道理，所以也就不讨论这种情况）

Algorithm end

你已经收集了几列，把它们都放到table的索引选项里。通常这些列都是帮助执行select的好的索引。下面是一些其他相关的建议。

一个在算法上可能是错误的示例:

SELECT ... FROM t WHERE flag = true;

这种情况（根据算法）会调用索引index（flag）。但是，如果对一列只有两个（或者很小数量）不同值的列做索引几乎是无效的。
这被称为low cardinality（低基数）。优化器更愿意去做一次全表扫描而不是一直在索引和数据之前来回切换。

另一种情况下，这个算法就是对的

SELECT ... FROM t WHERE flag = true AND date >= '2015-01-01';

这种情况下会调用一个聚合索引，并且flag顺序在前INDEX(flag,date). 这样的索引很有可能会有增益，而且肯定会比index(date)更加有效。

甚至在加上LIMIT后更有效果

SELECT ... FROM t WHERE flag = true AND date >= '2015-01-01' LIMIT 10;

在找了10行数据后index(flag,date)会停下来，而Index(date) 则不会。
如果添加索引的列有可能需要更新的话，那么更新可能会耗费额外的工作量，在b树中移除一行又新增一行，比如：

INDEX(x)
UPDATE t SET x = ... WHERE ...;

是要添加索引还是移除索引，实在是有太多变量要说了。
…（待续）

引用

index_cookbook_mysql