前言在之前“影响MySQL 应用系统性能的相关因素”一章中我们就已经分析过了Query 语句对数据库性能的影响非常大，所以本章将专门针对MySQL 的Query 语句的优化进行相应的分析。 8.1 理解MySQL的Query Optimizer8.1.1 MySQL Query Optimizer是什么？在“MySQL 架构组成”一章中的“MySQL 逻辑组成”一节中我们已经了解到，在MySQL 中有一个专门负责优化SELECT 语句的优化器模块，这就是我们本节将要重点分析的MySQL Optimizer，其主要的功能就是通过计算分析系统中收集的各种统计信息，为客户端请求的Query 给出他认为最优的执行计划，也就是他认为最优的数据检索方式。 当MySQL Optimizer 接收到从Query Parser （解析器）送过来的Query 之后，会根据MySQLQuery 语句的相应语法对该Query 进行分解分析的同时，还会做很多其他的计算转化工作。如常量转化，无效内容删除，常量计算等等。所有这些工作都只为了Optimizer 工作的唯一目的，分析出最优的数据检索方式，也就是我们常说的执行计划。 8.1.2 MySQL Query Optimizer基本工作原理在分析MySQL Optimizer 的工作原理之前，先了解一下MySQL 的Query Tree。MySQL 的Query Tree 是通过优化实现DBXP 的经典数据结构和Tree 构造器而生成的一个指导完成一个Query 语句的请求所 需要处理的工作步骤，我们可以简单的认为就是一个的数据处理流程规划，只不过是以一个Tree 的数据 结构存放而已。通过Query Tree 我们可以很清楚的知道一个Query 的完成需要经过哪些步骤的处理， 每一步的数据来源在哪里，处理方式是怎样的。在整个DBXP 的Query Tree 生成过程中，MySQL 使用了 LEX 和YACC 这两个功能非常强大的语法（词法）分析工具。MySQL Query Optimizer 的所有工作都是基 于这个Query Tree 所进行的。各位读者朋友如果对MySQL Query Tree 实现生成的详细信息比较感兴 趣，可以参考Chales A. Bell 的《Expert MySQL》这本书，里面有比较详细的介绍。 MySQL Query Optimizer 并不是一个纯粹的CBO（Cost Base Optimizer），而是在CBO 的基础上增 加了一个被称为Heuristic Optimize（启发式优化）的功能。也就是说，MySQL Query Optimizer 在优 化一个Query 选择出他认为的最优执行计划的时候，并不一定完全按照系数据库的元信息和系统统计信 息，而是在此基础上增加了某些特定的规则。其实我个人的理解就是在CBO 的实现中增加了部分 RBO（Rule Base Optimizer）的功能，以确保在某些特别的场景下控制Query 按照预定的方式生成执行 计划。 当客户端向MySQL 请求一条Query ，到命令解析器模块完成请求分类区别出是SELECT 并转发给 Query Optimizer 之后，Query Optimizer 首先会对整条Query 进行，优化处理掉一些常量表达式的预 算，直接换算成常量值。并对Query 中的查询条件进行简化和转换，如去掉一些无用或者显而易见的条 件，结构调整等等。然后则是分析Query 中的Hint 信息（如果有），看显示Hint 信息是否可以完全 确定该Query 的执行计划。如果没有Hint 或者Hint 信息还不足以完全确定执行计划，则会读取所涉 及对象的统计信息，根据Query 进行写相应的计算分析，然后再得出最后的执行计划。 Query Optimizer 是一个数据库软件非常核心的功能，虽然在这里说起来只是简单的几句话，但是 在MySQL 内部，Query Optimizer 实际上是经过了很多复杂的运算分析，才得出最后的执行计划。对于 MySQL Query Optimizer 更多的信息，各位读者可以通过MySQL Internal 文档进行更为全面的了解。 8.2 Query 语句优化基本思路和原则在分析如何优化MySQL Query 之前，我们需要先了解一下Query 语句优化的基本思路和原则。一 般来说，Query 语句的优化思路和原则主要提现在以下几个方面：
上面所列的几点信息，前面4 点可以理解为Query 优化的一个基本思路，后面部分则是我们优化中 的基本原则。 下面我们先针对Query 优化的基本思路做一些简单的分析，理解为什么我们的Query 优化到底该 如何进行。 优化更需要优化的Query 为什么我们需要优化更需要优化的Query？这个地球人都知道的“并不能成为问题的问题”我想就 并不需要我过多解释吧，哈哈。 那什么样的Query 是更需要优化呢？对于这个问题我们需要从对整个系统的影响来考虑。什么 Query 的优化能给系统整体带来更大的收益，就更需要优化。一般来说，高并发低消耗（相对）的 Query 对整个系统的影响远比低并发高消耗的Query 大。我们可以通过以下一个非常简单的案例分析来 充分说明问题。 假设有一个Query 每小时执行10000 次，每次需要20 个IO。另外一个Query 每小时执行10 次， 每次需要20000 个IO。 我们先通过IO 消耗方面来分析。可以看出，两个Query 每小时所消耗的IO 总数目是一样的，都是 200000 IO/小时。假设我们优化第一个Query，从20 个IO 降低到18 个IO，也就是仅仅降低了2 个IO， 则我们节省了2 * 10000 = 20000 （IO/小时）。而如果希望通过优化第二个Query 达到相同的效果， 我们必须要让每个Query 减少20000 / 10 = 2000 IO。我想大家都会相信让第一个Query 节省2 个IO 远比第二个Query 节省2000 个IO 来的容易。 其次，如果通过CPU 方面消耗的比较，原理和上面的完全一样。只要让第一个Query 稍微节省一 小块资源，就可以让整个系统节省出一大块资源，尤其是在排序，分组这些对CPU 消耗比较多的操作中 尤其突出。 最后，我们从对整个系统的影响来分析。一个频繁执行的高并发Query 的危险性比一个低并发的 Query 要大很多。当一个低并发的Query 走错执行计划，所带来的影响主要只是该Query 的请求者的 体验会变差，对整体系统的影响并不会特别的突出，之少还属于可控范围。但是，如果我们一个高并发 的Query 走错了执行计划，那所带来的后可很可能就是灾难性的，很多时候可能连自救的机会都不给你 就会让整个系统Crash 掉。曾经我就遇到这样一个案例，系统中一个并发度较高的Query 语句走错执 行计划，系统顷刻间Crash，甚至我都还没有反应过来是怎么回事。当重新启动数据库提供服务后，系 统负载立刻直线飙升，甚至都来不及登录数据库查看当时有哪些Active 的线程在执行哪些Query。如 果是遇到一个并发并不太高的Query 走错执行计划，至少我们还可以控制整个系统不至于系统被直接压 跨，甚至连问题根源都难以抓到。 定位优化对象的性能瓶颈 当我们拿到一条需要优化的Query 之后，第一件事情是什么？是反问自己，这条Query 有什么问 题？我为什么要优化他？只有明白了这些问题，我们才知道我们需要做什么，才能够找到问题的关键。 而不能就只是觉得某个Query 好像有点慢，需要优化一下，然后就开始一个一个优化方法去轮番尝试。 这样很可能整个优化过程会消耗大量的人力和时间成本，甚至可能到最后还是得不到一个好的优化结 果。这就像看病一样，医生必须要清楚的知道我们病的根源才能对症下药。如果只是知道我们什么地方 不舒服，然后就开始通过各种药物尝试治疗，那这样所带来的后果可能就非常严重了。 所以，在拿到一条需要优化的Query 之后，我们首先要判断出这个Query 的瓶颈到底是IO 还是 CPU。到底是因为在数据访问消耗了太多的时间，还是在数据的运算（如分组排序等）方面花费了太多资 源？ 一般来说，在MySQL 5.0 系列版本中，我们可以通过系统自带的PROFILING 功能很清楚的找出一个 Query 的瓶颈所在。当然，如果读者朋友为了使用MySQL 的某些在5.1 版本中才有的新特性（如 Partition，EVENT 等）亦或者是比较喜欢尝试新事务而早早使用的MySQL 5.1 的预发布版本，可能就没 办法使用这个功能了，因为该功能在MySQL5.1 系列刚开始的版本中并不支持，不过让人非常兴奋的是该 功能在最新出来的MySQL 5.1 正式版（5.1.30）又已经提供了。而如果读者朋友正在使用的MySQL 是 4.x 版本，那可能就只能通过自行分析Query 的各个执行步骤，找到性能损失最大的地方。 明确的优化目标 当我们定为到了一条Query 的性能瓶颈之后，就需要通过分析该Query 所完成的功能和Query 对 系统的整体影响制订出一个明确的优化目标。没有一个明确的目标，优化过程将是一个漫无目的而且低 效的过程，也很难达收到一个理想的效果。尤其是对于一些实现应用中较为重要功能点的Query 更是如 此。 如何设定优化目标？这可能是很多人都非常头疼的问题，对于我自己也一样。要设定一个合理的优 化目标，不能过于理想也不能放任自由，确实是一件非常头疼的事情。一般来说，我们首先需要清楚的 了解数据库目前的整体状态，同时也要清楚的知道数据库中与该Query 相关的数据库对象的各种信息， 而且还要了解该Query 在整个应用系统中所实现的功能。了解了数据库整体状态，我们就能知道数据库 所能承受的最大压力，也就清楚了我们能够接受的最悲观情况。把握了该Query 相关数据库对象的信 息，我们就应该知道实现该Query 的消耗最理想情况下需要消耗多少资源，最糟糕又需要消耗多少资 源。最后，通过该Query 所实现的功能点在整个应用系统中的重要地位，我们可以大概的分析出该 Query 可以占用的系统资源比例，而且我们也能够知道该Query 的效率给客户带来的体验影响到底有多 大。 当我们清楚了这些信息之后，我们基本可以得出该Query 应该满足的一个性能范围是怎样的，这也 就是我们的优化目标范围，然后就是通过寻找相应的优化手段来解决问题了。如果该Query 实现的应用 系统功能比较重要，我们就必须让目标更偏向于理想值一些，即使在其他某些方面作出一些让步与牺 牲，比如调整schema 设计，调整索引组成等，可能都是需要的。而如果该Query 所实现的是一些并不 是太关键的功能，那我们可以让目标更偏向悲观值一些，而尽量保证其他更重要的Query 的性能。这种 时候，即使需要调整商业需求，减少功能实现，也不得不应该作出让步。 从Explain 入手 现在，优化目标也已经明确了，自然是奥开始动手的时候了。我们的优化到底该从何处入手呢？答 案只有一个，从Explain 开始入手。为什么？因为只有Explain 才能告诉你，这个Query 在数据库中是 以一个什么样的执行计划来实现的。 但是，有一点我们必须清楚，Explain 只是用来获取一个Query 在当前状态的数据库中的执行计 划，在优化动手之前，我们比需要根据优化目标在自己头脑中有一个清晰的目标执行计划。只有这样， 优化的目标才有意义。一个优秀的SQL 调优人员（或者成为SQL Performance Tuner），在优化任何一 个SQL 语句之前，都应该在自己头脑中已经先有一个预定的执行计划，然后通过不断的调整尝试，再借 助Explain 来验证调整的结果是否满足自己预定的执行计划。对于不符合预期的执行计划需要不断分析 Query 的写法和数据库对象的信息，继续调整尝试，直至得到预期的结果。 当然，人无完人，并不一定每次自己预设的执行计划都肯定是最优的，在不断调整测试的过程中， 如果发现MySQL Optimizer 所选择的执行计划的实际执行效果确实比自己预设的要好，我们当然还是应 该选择使用MySQL optimizer 所生成的执行计划。 上面的这个优化思路，只是给大家指了一个优化的基本方向，实际操作还需要读者朋友不断的结合 具体应用场景不断的测试实践来体会。当然也并不一定所有的情况都非要严格遵循这样一个思路，规则 是死的，人是活的，只有更合理的方法，没有最合理的规则。 在了解了上面这些优化的基本思路之后，我们再来看看优化的几个基本原则。 永远用小结果集驱动大的结果集 很多人喜欢在优化SQL 的时候说用小表驱动大表，个人认为这样的说法不太严谨。为什么？因 为大表经过WHERE 条件过滤之后所返回的结果集并不一定就比小表所返回的结果集大，可能反而更小。 在这种情况下如果仍然采用小表驱动大表，就会得到相反的性能效果。 其实这样的结果也非常容易理解，在MySQL 中的Join，只有Nested Loop 一种Join 方式，也就是 MySQL 的Join 都是通过嵌套循环来实现的。驱动结果集越大，所需要循环的此时就越多，那么被驱动表 的访问次数自然也就越多，而每次访问被驱动表，即使需要的逻辑IO 很少，循环次数多了，总量自然也 不可能很小，而且每次循环都不能避免的需要消耗CPU ，所以CPU 运算量也会跟着增加。所以，如果 我们仅仅以表的大小来作为驱动表的判断依据，假若小表过滤后所剩下的结果集比大表多很多，结果就 是需要的嵌套循环中带来更多的循环次数，反之，所需要的循环次数就会更少，总体IO 量和CPU 运算 量也会少。而且，就算是非Nested Loop 的Join 算法，如Oracle 中的Hash Join，同样是小结果集 驱动大的结果集是最优的选择。 所以，在优化Join Query 的时候，最基本的原则就是“小结果集驱动大结果集”，通过这个原则 来减少嵌套循环中的循环次数，达到减少IO 总量以及CPU 运算的次数。 尽可能在索引中完成排序 只取出自己需要的Columns 任何时候在Query 中都只取出自己需要的Columns，尤其是在需要排序的Query 中。为什么？ 对于任何Query，返回的数据都是需要通过网络数据包传回给客户端，如果取出的Column 越多， 需要传输的数据量自然会越大，不论是从网络带宽方面考虑还是从网络传输的缓冲区来看，都是一个浪 费。 如果是需要排序的Query 来说，影响就更大了。在MySQL 中存在两种排序算法，一种是在 MySQL4.1 之前的老算法，实现方式是先将需要排序的字段和可以直接定位到相关行数据的指针信息取 出，然后在我们所设定的排序区（通过参数sort_buffer_size 设定）中进行排序，完成排序之后再次 通过行指针信息取出所需要的Columns，也就是说这种算法需要访问两次数据。第二种排序算法是从 MySQL4.1 版本开始使用的改进算法，一次性将所需要的Columns 全部取出，在排序区中进行排序后直 接将数据返回给请求客户端。改行算法只需要访问一次数据，减少了大量的随机IO，极大的提高了带有 排序的Query 语句的效率。但是，这种改进后的排序算法需要一次性取出并缓存的数据比第一种算法 要多很多，如果我们将并不需要的Columns 也取出来，就会极大的浪费排序过程所需要的内存。在 MySQL4.1 之后的版本中，我们可以通过设置max_length_for_sort_data 参数大小来控制MySQL 选择 第一种排序算法还是第二种排序算法。当所取出的Columns 的单条记录总大于max_length_for_sort_data 设置的大小的时候，MySQL 就会选择使用第一种排序算法，反之，则会选 择第二种优化后的算法。为了尽可能提高排序性能，我们自然是更希望使用第二种排序算法，所以在 Query 中仅仅取出我们所需要的Columns 是非常有必要的。 仅仅使用最有效的过滤条件 很多人在优化Query 语句的时候很容易进入一个误区，那就是觉得WHERE 子句中的过滤条件越多 越好，实际上这并不是一个非常正确的选择。其实我们分析Query 语句的性能优劣最关键的就是要让他 选择一条最佳的数据访问路径，如何做到通过访问最少的数据量完成自己的任务。 为什么说过滤条件多不一定是好事呢？请看下面示例：
需求： 查找某个用户在所有group 中所发的讨论message 基本信息。 场景： 1、知道用户ID 和用户nick_name 方案一：将用户ID 和用户nick_name 两者都作为过滤条件放在WHERE 子句中来查询，Query 的执行计 划如下：
sky@localhost : example 11:29:37> EXPLAIN SELECT * FROM group_message 方案二：仅仅将用户ID 作为过滤条件放在WHERE 子句中来查询，Query 的执行计划如下：
sky@localhost : example 11:30:45> EXPLAIN SELECT * FROM group_message 方案二：仅将用户nick_name 作为过滤条件放在WHERE 子句中来查询，Query 的执行计划如下：
sky@localhost : example 11:38:45> EXPLAIN SELECT * FROM group_message 初略一看三个执行计划好像都挺好的啊，每一个Query 的执行类型都利用到了索引，而且都是 “ref”类型。可是仔细一分析，就会发现，group_message_uid_ind 索引的索引键长度为4（key_len: 4），由于user_id 字段类型为int，所以我们可以判定出Query Optimizer 给出的这个索引键长度是 完全准确的。而group_message_author_ind 索引的索引键长度为98（key_len: 98），因为author 字 段定义为varchar(32) ，而所使用的字符集是utf8，32 * 3 + 2 = 98。而且，由于user_id 与 author（来源于nick_name）全部都是一一对应的，所以同一个user_id 有哪些记录，那么所对应的 author 也会有完全相同的记录。所以，同样的数据在group_message_author_ind 索引中所占用的存储 空间要远远大于group_message_uid_ind 索引所占用的空间。占用空间更大，代表我们访问该索引所需 要读取的数据量就会更多。所以，选择group_message_uid_ind 的执行计划才是最有的执行计划。也就 是说，上面的方案二才是最有方案，而使用了更多的WHERE 条件的方案一反而没有仅仅使用user_id 一个过滤条件的方案一优。 可能有些人会说，那如果将user_id 和author 两者建立联合索引呢？告诉你，效果可能比没有这 个索引的时候更差，因为这个联合索引的索引键更长，索引占用的空间将会更大。 这个示例并不一定能代表所有场景，仅仅是希望让大家明白，并不是任何时候都是使用的过滤条件 越多性能会越好。在实际应用场景中，肯定会存在更多更复杂的情形，怎样使我们的Query 有一个更优 化的执行计划，更高效的性能，还需要靠大家仔细分析各种执行计划的具体差别，才能选择出更优化的 Query。 尽可能避免复杂的Join 和子查询 我们都知道，MySQL 在并发这一块做的并不是太好，当并发量太高的时候，系统整体性能可能会急 剧下降，尤其是遇到一些较为复杂的Query 的时候更是如此。这主要与MySQL 内部资源的争用锁定控 制有关，如读写相斥等等。对于Innodb 存储引擎由于实现了行级锁定可能还要稍微好一些，如果使用 的MyISAM 存储引擎，并发一旦较高的时候，性能下降非常明显。所以，我们的Query 语句所涉及到的 表越多，所需要锁定的资源就越多。也就是说，越复杂的Join 语句，所需要锁定的资源也就越多，所 阻塞的其他线程也就越多。相反，如果我们将比较复杂的Query 语句分拆成多个较为简单的Query 语 句分步执行，每次锁定的资源也就会少很多，所阻塞的其他线程也要少一些。 可能很多读者会有疑问，将复杂Join 语句分拆成多个简单的Query 语句之后，那不是我们的网络 交互就会更多了吗？网络延时方面的总体消耗也就更大了啊，完成整个查询的时间不是反而更长了吗？ 是的，这种情况是可能存在，但也并不是肯定就会如此。我们可以再分析一下，一个复杂的Join Query 语句在执行的时候，所需要锁定的资源比较多，可能被别人阻塞的概率也就更大，如果是一个简单的 Query，由于需要锁定的资源较少，被阻塞的概率也会小很多。所以较为复杂的Join Query 也有可能 在执行之前被阻塞而浪费更多的时间。而且，我们的数据库所服务的并不是单单这一个Query 请求，还 有很多很多其他的请求，在高并发的系统中，牺牲单个Query 的短暂响应时间而提高整体处理能力也是 非常值得的。优化本身就是一门平衡与取舍的艺术，只有懂得取舍，平衡整体，才能让系统更优。 对于子查询，可能不需要我多说很多人就明白为什么会不被推荐使用。在MySQL 中，子查询的实现 目前还比较差，很难得到一个很好的执行计划，很多时候明明有索引可以利用，可Query Optimizer 就 是不用。从MySQL 官方给出的信息说，这一问题将在MySQL6.0 中得到较好的解决，将会引入 SemiJoin 的执行计划，可MySQL6.0 离我们投入生产环境使用恐怕还有很遥远的一段时间。所以，在 Query 优化的过程中，能不用子查询的时候就尽量不要使用子查询。 上面这些仅仅只是一些常用的优化原则，并不是说在Query 优化中就只需要做到这些原则就可以， 更不是说Query 优化只能通过这些原则来优化。在实际优化过程中，我们还可能会遇到很多带有较为复 杂商业逻辑的场景，具体的优化方法就只能根据不同的应用场景来具体分析，逐步调整。其实，最有效 的优化，就是不要用，也就是不要实现这个商业需求。 8.3 充分利用Explain 和Profiling8.3.1 Explain 的使用说到Explain，肯定很多读者之前都都已经用过了，MySQL Query Optimizer 通过我让们执行 EXPLAIN 命令来告诉我们他将使用一个什么样的执行计划来优化我们的Query。所以，可以说Explain 是在优化Query 时最直接有效的验证我们想法的工具。在本章前面部分我就说过，一个好的SQL Performance Tuner 在动手优化一个Query 之前，头脑中就应该已经有一个好的执行计划，后面的优化 工作只是为实现该执行计划而作出各种调整。 在我们对某个Query 优化过程中，需要不断的使用Explain 来验证我们的各种调整是否有效。就 像本书之前的很多示例都会通过Explain 来验证和展示结果一样，所有的Query 优化都应该充分利用 他。 我们先看一下在MySQL Explain 功能中给我们展示的各种信息的解释：
这里我们通过分析示例来看一下不同的Query 语句通过Explain 所显示的不同信息： 我们先看一个简单的单表Query：
sky@localhost : example 11:33:18> explain select count(*),max(id),min(id) 对user 表的单表查询，查询类型为SIMPLE，因为既没有UNION 也不是子查询。聚合函数MAX MIN 以及COUNT 三者所需要的数据都可以通过索引就能够直接定位得到数据，所以整个实现的Extra 信息 为Select tables optimized away。 再来看一个稍微复杂一点的Query，一个子查询：
sky@localhost : example 11:38:48> explain select name from groups 通过id 信息我们可以得知MySQL Query Optimizer 给出的执行计划是首先对groups 进行全表扫 描，然后第二步才访问user_group 表，所使用的查询方式是DEPENDENT SUBQUERY，对所需数据的访问 方式是索引扫描，由于过滤条件是一个整数，所以索引扫描的类型为ref，过滤条件是const。可以使 用的索引有两个，一个是基于user_id，另一个则是基于group_id 的。为什么基于group_id 的索引 user_group_gid_ind 也被列为可选索引了呢？是因为与子查询的外层查询所关联的条件是基于 group_id 的。当然，最后MySQL Query Optimizer 还是选择了使用基于user_id 的索引 user_group_uid_ind。 由于篇幅关系，这里就不再继续举例了，大家可以通过自行通过Explain 功能分析各自应用环境中 的各种Query，了解他们在我们的MySQL 中到底是怎么运行的。 8.3.2 Profiling 的使用在本章第一节中我们还提到过通过Query Profiler 来定位一条Query 的性能瓶颈，这里我们再详 细介绍一下Profiling 的用途及使用方法。 要想优化一条Query，我们就需要清楚的知道这条Query 的性能瓶颈到底在哪里，是消耗的CPU 计算太多，还是需要的的IO 操作太多？要想能够清楚的了解这些信息，在MySQL 5.0 和MySQL 5.1 正式版中已经可以非常容易做到了，那就是通过Query Profiler 功能。 MySQL 的Query Profiler 是一个使用非常方便的Query 诊断分析工具，通过该工具可以获取一条 Query 在整个执行过程中多种资源的消耗情况，如CPU，IO，IPC，SWAP 等，以及发生的PAGE FAULTS， CONTEXT SWITCHE 等等，同时还能得到该Query 执行过程中MySQL 所调用的各个函数在源文件中的位 置。下面我们看看Query Profiler 的具体用法。 1、开启profiling 参数
root@localhost : (none) 10:53:11> set profiling=1; 在开启Query Profiler 功能之后，MySQL 就会自动记录所有执行的Query 的profile 信息了。 3、获取系统中保存的所有Query 的profile 概要信息
root@localhost : test 07:47:35> show profiles; 通过执行“SHOW PROFILE” 命令获取当前系统中保存的多个Query 的profile 的概要信息。 4、针对单个Query 获取详细的profile 信息。 在获取到概要信息之后，我们就可以根据概要信息中的Query_ID 来获取某个Query 在执行过程中 详细的profile 信息了，具体操作如下：
root@localhost : test 07:49:24> show profile cpu, block io for query 6; 上面的例子中是获取CPU 和Block IO 的消耗，非常清晰，对于定位性能瓶颈非常适用。希望得到 取其他的信息，都可以通过执行“SHOW PROFILE *** FOR QUERY n” 来获取，各位读者朋友可以自行 测试熟悉。 8.4 合理设计并利用索引索引，可以说是数据库相关优化尤其是在Query 优化中最常用的优化手段之一了。但是很多人在大 部分时候都只是大概了解索引的用途，知道索引能够让Query 执行的更快，而并不知道为什么会更快。 尤其是索引的实现原理，存储方式，以及不同索引之间的区别等就更不是太清楚了。正因为索引对我们 的Query 性能影响很大，所以我们更应该深入理解MySQL 中索引的基本实现，以及不同索引之间的区 别，才能分析出如何设计出最优的索引来最大幅度的提升Query 的执行效率。 在MySQL 中，主要有四种类型的索引，分别为：B-Tree 索引，Hash 索引，Fulltext 索引和RTree 索引，下面针对这四种索引的基本实现方式及存储结构做一个大概的分析。 B-Tree 索引 B-Tree 索引是MySQL 数据库中使用最为频繁的索引类型，除了Archive 存储引擎之外的其他所有 的存储引擎都支持B-Tree 索引。不仅仅在MySQL 中是如此，实际上在其他的很多数据库管理系统中 B-Tree 索引也同样是作为最主要的索引类型，这主要是因为B-Tree 索引的存储结构在数据库的数据检 索中有非常优异的表现。 一般来说，MySQL 中的B-Tree 索引的物理文件大多都是以Balance Tree 的结构来存储的，也就 是所有实际需要的数据都存放于Tree 的Leaf Node，而且到任何一个Leaf Node 的最短路径的长度都 是完全相同的，所以我们大家都称之为B-Tree 索引当然，可能各种数据库（或MySQL 的各种存储引 擎）在存放自己的B-Tree 索引的时候会对存储结构稍作改造。如Innodb 存储引擎的B-Tree 索引实 际使用的存储结构实际上是B+Tree，也就是在B-Tree 数据结构的基础上做了很小的改造，在每一个 Leaf Node 上面出了存放索引键的相关信息之外，还存储了指向与该Leaf Node 相邻的后一个Leaf Node 的指针信息，这主要是为了加快检索多个相邻Leaf Node 的效率考虑。 在Innodb 存储引擎中，存在两种不同形式的索引，一种是Cluster 形式的主键索引（Primary Key），另外一种则是和其他存储引擎（如MyISAM 存储引擎）存放形式基本相同的普通B-Tree 索引， 这种索引在Innodb 存储引擎中被称为Secondary Index。下面我们通过图示来针对这两种索引的存放 形式做一个比较。
图示中左边为Clustered 形式存放的Primary Key，右侧则为普通的B-Tree 索引。两种索引在 Root Node 和Branch Nodes 方面都还是完全一样的。而Leaf Nodes 就出现差异了。在Primary Key 中，Leaf Nodes 存放的是表的实际数据，不仅仅包括主键字段的数据，还包括其他字段的数据，整个数 据以主键值有序的排列。而Secondary Index 则和其他普通的B-Tree 索引没有太大的差异，只是在 Leaf Nodes 出了存放索引键的相关信息外，还存放了Innodb 的主键值。 所以，在Innodb 中如果通过主键来访问数据效率是非常高的，而如果是通过Secondary Index 来 访问数据的话，Innodb 首先通过Secondary Index 的相关信息，通过相应的索引键检索到Leaf Node 之后，需要再通过Leaf Node 中存放的主键值再通过主键索引来获取相应的数据行。 MyISAM 存储引擎的主键索引和非主键索引差别很小，只不过是主键索引的索引键是一个唯一且非空 的键而已。而且MyISAM 存储引擎的索引和Innodb 的Secondary Index 的存储结构也基本相同，主要 的区别只是MyISAM 存储引擎在Leaf Nodes 上面出了存放索引键信息之外，再存放能直接定位到 MyISAM 数据文件中相应的数据行的信息（如Row Number），但并不会存放主键的键值信息。 Hash 索引 Hash 索引在MySQL 中使用的并不是很多，目前主要是Memory 存储引擎使用，而且在Memory 存 储引擎中将Hash 索引作为默认的索引类型。所谓Hash 索引，实际上就是通过一定的Hash 算法，将 需要索引的键值进行Hash 运算，然后将得到的Hash 值存入一个Hash 表中。然后每次需要检索的时 候，都会将检索条件进行相同算法的Hash 运算，然后再和Hash 表中的Hash 值进行比较并得出相应 的信息。 在Memory 存储引擎中，MySQL 还支持非唯一的Hash 索引。可能很多人会比较惊讶，如果是非唯 一的Hash 索引，那相同的值该如何处理呢？在Memory 存储引擎的Hash 索引中，如果遇到非唯一 值，存储引擎会将他们链接到同一个hash 键值下以一个链表的形式存在，然后在取得实际键值的时候 时候再过滤不符合的键。 由于Hash 索引结构的特殊性，其检索效率非常的高，索引的检索可以一次定位，而不需要像BTree 索引需要从根节点再到枝节点最后才能访问到页节点这样多次IO 访问，所以Hash 索引的效率要 远高于B-Tree 索引。 可能很多人又会有疑问了，既然Hash 索引的效率要比B-Tree 高很多，为什么大家不都用Hash 索引而还要使用B-Tree 索引呢？任何事物都是有两面性的，，Hash 索引也一样，虽然Hash 索引检 索效率非常之高，但是Hash 索引本身由于其实的特殊性也带来了很多限制和弊端，主要有以下这些： 1. Hash 索引仅仅只能满足“=”,“IN”和“<=>”查询，不能使用范围查询； 由于Hash 索引所比较的是进行Hash 运算之后的Hash 值，所以Hash 索引只能用于等值的 过滤，而不能用于基于范围的过滤，因为经过相应的Hash 算法处理之后的Hash 值的大小关 系，并不能保证还和Hash 运算之前完全一样。 2. Hash 索引无法被利用来避免数据的排序操作； 由于Hash 索引中存放的是经过Hash 计算之后的Hash 值，而且Hash 值的大小关系并不一定 和Hash 运算前的键值的完全一样，所以数据库无法利用索引的数据来避免任何和排序运算； 3. Hash 索引不能利用部分索引键查询； 对于组合索引，Hash 索引在计算Hash 值的时候是组合索引键合并之后再一起计算Hash 值， 而不是单独计算Hash 值，所以当我们通过组合索引的前面一个或几个索引键进行查询的时 候，Hash 索引也无法被利用到； 4. Hash 索引在任何时候都不能避免表扫面； 前面我们已经知道，Hash 索引是将索引键通过Hash 运算之后，将Hash 运算结果的Hash 值 和所对应的行指针信息存放于一个Hash 表中，而且由于存在不同索引键存在相同Hash 值的 可能，所以即使我们仅仅取满足某个Hash 键值的数据的记录条数，都无法直接从Hash 索引 中直接完成查询，还是要通过访问表中的实际数据进行相应的比较而得到相应的结果。 5. Hash 索引遇到大量Hash 值相等的情况后性能并不一定就会比B-Tree 索引高； 对于选择性比较低的索引键，如果我们创建Hash 索引，那么我们将会存在大量记录指针信息 存与同一个Hash 值相关连。这样要定位某一条记录的时候就会非常的麻烦，可能会浪费非常 多次表数据的访问，而造成整体性能的地下。 Full-text 索引 Full-text 索引也就是我们常说的全文索引，目前在MySQL 中仅有MyISAM 存储引擎支持，而且也 并不是所有的数据类型都支持全文索引。目前来说，仅有CHAR，VARCHAR 和TEXT 这三种数据类型的列可 以建Full-text 索引。 一般来说，Fulltext 索引主要用来替代效率低下的LIKE '%***%' 操作。实际上，Full-text 索引 并不只是能简单的替代传统的全模糊LIKE 操作，而且能通过多字段组合的Full-text 索引一次全模糊 匹配多个字段。 Full-text 索引和普通的B-Tree 索引的实现区别较大，虽然他同样是以B-Tree 形式来存放索引 数据，但是他并不是通过字段内容的完整匹配，而是通过特定的算法，将字段数据进行分隔后再进行的 索引。一般来说MySQL 系统会按照四个字节来分隔。在整个Full-text 索引中，存储内容被分为两部 分，一部分是分隔前的索引字符串数据集合，另一部分是分隔后的词（或者词组）的索引信息。所以， Full-text 索引中，真正在B-Tree 索引细细中的并不是我们表中的原始数据，而是分词之后的索引数 据。在B-Tree 索引的节点信息中，存放了各个分隔后的词信息，以及指向包含该词的分隔前字符串信 息在索引数据集合中的位置信息。 Full-text 索引不仅仅能实现模糊匹配查找，在实现了基于自然语言的的匹配度查找。当然，这个 匹配读到底有多准确就需要读者朋友去自行验证了。Full-text 通过一些特定的语法信息，针对自然语 言做了各种相应规则的匹配，最后给出非负的匹配值。 此外，有一点是需要大家注意的，MySQL 目前的Full-text 索引在中文支持方面还不太好，需要借 助第三方的补丁或者插件来完成。而且Full-text 的创建所消耗的资源也是比较大的，所以在应用于实 际生产环境之前还是尽量做好评估。 关于Full-text 的实际使用方法由于不是本书的重点，感兴趣的读者朋友可以自行参阅MySQL 关 于Full-text 相关的使用手册来了解更为详尽的信息。 R-Tree 索引 R-Tree 索引可能是我们在其他数据库中很少见到的一种索引类型，主要用来解决空间数据检索的问 题。 在MySQL 中，支持一种用来存放空间信息的数据类型GEOMETRY，且基于OpenGIS 规范。在 MySQL5.0.16 之前的版本中，仅仅MyISAM 存储引擎支持该数据类型，但是从MySQL5.0.16 版本开始， BDB，Innodb，NDBCluster 和Archive 存储引擎也开始支持该数据类型。当然，虽然多种存储引擎都开 始支持GEOMETRY 数据类型，但是仅仅之后MyISAM 存储引擎支持R-Tree 索引。 在MySQL 中采用了具有二次分裂特性的R-Tree 来索引空间数据信息，然后通过几何对象（MRB） 信息来创建索引。 虽然仅仅只有MyISAM 存储引擎支持空间索引（R-Tree Index），但是如果我们是精确的等值匹 配，创建在空间数据上面的B-Tree 索引同样可以起到优化检索的效果，空间索引的主要优势在于当我 们使用范围查找的时候，可以利用到R-Tree 索引，而这时候，B-Tree 索引就无能为力了。 对于R-Tree 索引的详细介绍和使用信息清参阅MySQL 使用手册。 索引的利弊与如何判定是否需要索引 相信没一位读者朋友都知道索引能够极大的提高我们数据检索的效率，让我们的Query 执行的更 快，但是可能并不是每一位朋友都清楚索引在极大提高检索效率的同时，也给我们的数据库带来了一些 负面的影响。下面我们就分别对MySQL 中索引的利与弊做一个简单的分析。 索引的利处 索引能够给我们带来的最大益处可能读者朋友基本上都有一定的了解，但是我相信并不是每一位读 者朋友都能够了解的比较全面。很多朋友对数据库中的索引的认识可能主要还是只限于“能够提高数据 检索的效率，降低数据库的IO 成本”。 确实，在数据库中个表的某个字段创建索引，所带来的最大益处就是将该字段作为检索条件的时候 可以极大的提高检索效率，加快检索时间，降低检索过程中所需要读取的数据量。但是索引所给我们带 来的收益只是提高表数据的检索效率吗？当然不是，索引还有一个非常重要的用途，那就是降低数据的 排序成本。 我们知道，每个索引中索引数据都是按照索引键键值进行排序后存放的，所以，当我们的Query 语 句中包含排序分组操作的时候，如果我们的排序字段和索引键字段刚好一致，MySQL Query Optimizer 就会告诉mysqld 在取得数据之后不用排序了，因为根据索引取得的数据已经是满足客户的排序要求。 那如果是分组操作呢？分组操作没办法直接利用索引完成。但是分组操作是需要先进行排序然后才 分组的，所以当我们的Query 语句中包含分组操作，而且分组字段也刚好和索引键字段一致，那么 mysqld 同样可以利用到索引已经排好序的这个特性而省略掉分组中的排序操作。 排序分组操作主要消耗的是我们的内存和CPU 资源，如果我们能够在进行排序分组操作中利用好索 引，将会极大的降低CPU 资源的消耗。 索引的弊端 索引的益处我们都已经清楚了，但是我们不能光看到索引给我们带来的这么多益处之后就认为索引 是解决Query 优化的圣经，只要发现Query 运行不够快就将WHERE 子句中的条件全部放在索引中。 确实，索引能够极大的提高数据检索效率，也能够改善排序分组操作的性能，但是我们不能忽略的 一个问题就是索引是完全独立于基础数据之外的一部分数据。假设我们在Table ta 中的Column ca 创 建了索引idx_ta_ca，那么任何更新Column ca 的操作，MySQL 都需要在更新表中Column ca 的同时， 也更新Column ca 的索引数据，调整因为更新所带来键值变化后的索引信息。而如果我们没有对 Column ca 进行索引的话,MySQL 所需要做的仅仅只是更新表中Column ca 的信息。这样，所带来的最 明显的资源消耗就是增加了更新所带来的IO 量和调整索引所致的计算量。此外，Column ca 的索引 idx_ta_ca 是需要占用存储空间的，而且随着Table ta 数据量的增长，idx_ta_ca 所占用的空间也会 不断增长。所以索引还会带来存储空间资源消耗的增长。 如何判定是否需要创建索引 在了解了索引的利与弊之后，我们知道了索引并不是越多越好，知道了索引也是会带来副作用的。 那我们到底该如何来判断某个索引是否应该创建呢？ 实际上，并没有一个非常明确的定律可以清晰的定义出什么字段应该创建索引什么字段不该创建索 引。因为我们的应用场景实在是太复杂，存在太多的差异。当然，我们还是仍然能够找到几点基本的判 定策略来帮助我们分析是否需要创建索引。 ◆ 较频繁的作为查询条件的字段应该创建索引； 提高数据查询检索的效率最有效的办法就是减少需要访问的数据量，从上面所了解到的索引的 益处中我们知道了，索引正是我们减少通过索引键字段作为查询条件的Query 的IO 量的最有 效手段。所以一般来说我们应该为较为频繁的查询条件字段创建索引。 ◆ 唯一性太差的字段不适合单独创建索引，即使频繁作为查询条件； 唯一性太差的字段主要是指哪些呢？如状态字段，类型字段等等这些字段中存方的数据可能总 共就是那么几个几十个值重复使用，每个值都会存在于成千上万或是更多的记录中。对于这类 字段，我们完全没有必要创建单独的索引的。因为即使我们创建了索引，MySQL Query Optimizer 大多数时候也不会去选择使用，如果什么时候MySQL Query Optimizer 抽了一下风 选择了这种索引，那么非常遗憾的告诉你，这可能会带来极大的性能问题。由于索引字段中每 个值都含有大量的记录，那么存储引擎在根据索引访问数据的时候会带来大量的随机IO，甚 有些时候可能还会出现大量的重复IO。 这主要是由于数据基于索引扫描的特点所引起的。当我们通过索引访问表中的数据的时候， MySQL 会按照索引键的键值的顺序来依序进行访问。一般来说每个数据页中大都会存放多条记 录，但是这些记录可能大多数都不会是和你所使用的索引键的键值顺序一致。 假如有以下场景，我们通过索引查找键值为A 和B 的某些数据。当我们先通过A 键值找到第一 条满足要求的记录后，我们会读取这条记录所在的X 数据页，然后我们继续往下查找索引，发 现A 键值所对应的另外一条记录也满足我们的要求，但是这条记录不在X 数据页上面，而在 Y 数据页上面，这时候存储引擎就会丢弃X 数据页，而读取Y 数据页。如此继续一直到查找 完A 键值所对应的所有记录。然后轮到B 键值了，这时候发现正在查找的记录又在X 数据页 上面，可之前读取的X 数据页已经被丢弃了，只能再次读取X 数据页。这时候，实际上已 出现重复读取X 数据页两次了。在继续往后的查找中，可能还会出现一次又一次的重复读取。 这无疑极大的给存储引擎增大了IO 访问量。 不仅如此，如果一个键值对应了太多的数据记录，也就是说通过该键值会返回占整个表比例很 大的记录的时候，由于根据索引扫描产生的都是随机IO，其效率比进行全表扫描的顺序IO 的 效率要差很多，即使不会出现重复IO 的读取，同样会造成整体IO 性能的下降。 很多比较有经验的Query 调优专家经常说，当一条Query 所返回的数据超过了全表的15% 的 时候，就不应该再使用索引扫描来完成这个Query 了。对于“15%”这个数字我们并不能判定 是否很准确，但是之少侧面证明了唯一性太差的字段并不适合创建索引。 ◆ 更新非常频繁的字段不适合创建索引； 上面在索引的弊端中我们已经分析过了，索引中的字段被更新的时候，不仅仅需要更新表中的 数据，同时还要更新索引数据，以确保索引信息是准确的。这个问题所带来的是IO 访问量的较大 增加，不仅仅影响更新Query 的响应时间，还会影响整个存储系统的资源消耗，加大整个存储系统 的负载。 当然，并不是存在更新的字段就比适合创建索引，从上面判定策略的用语上面也可以看出，是 “非常频繁”的字段。到底什么样的更新频率应该算是“非常频繁”呢？每秒，每分钟，还是每小 时呢？说实话，这个还真挺难定义的。很多时候还是通过比较同一时间段内被更新的次数和利用该 字段作为条件的查询次数来判断，如果通过该字段的查询并不是很多，可能几个小时或者是更长才 会执行一次，而更新反而比查询更频繁，那这样的字段肯定不适合创建索引。反之，如果我们通过 该字段的查询比较频繁，而且更新并不是特别多，比如查询十几二十次或是更多才可能会产生一次 更新，那我个人觉得更新所带来的附加成本也是可以接受的。 ◆ 不会出现在WHERE 子句中的字段不该创建索引； 不会还有人会问为什么吧？自己也觉得这是废话了，哈哈！ 单键索引还是组合索引 在大概了解了一下MySQL 各种类型的索引以及索引本身的利弊与判断一个字段是否需要创建索引之 后，我们就需要着手创建索引来优化我们的Query 了。在很多时候，我们的WHERE 子句中的过滤条件 并不只是针对于单一的某个字段，而是经常会有多个字段一起作为查询过滤条件存在于WHERE 子句中。 在这种时候，我们就必须要作出判断，是该仅仅为过滤性最好的字段建立索引还是该在所有字段（过滤 条件中的）上面建立一个组合索引呢？ 对于这种问题，很难有一个绝对的定论，我们需要从多方面来分析考虑，平衡两种方案各自的优 劣，然后选择一种最佳的方案来解决。因为从上一节中我们了解到了索引在提高某些查询的性能的同 时，也会让某些更新的效率下降。而组合索引中因为有多个字段的存在，理论上被更新的可能性肯定比 单键索引要大很多，这样可能带来的附加成本也就比单键索引要高。但是，当我们的WHERE 子句中的查 询条件含有多个字段的时候，通过这多个字段共同组成的组合索引的查询效率肯定比仅仅只用过滤条件 中的某一个字段创建的索引要高。因为通过单键索引所能过滤的数据并不完整，和通过组合索引相比， 存储引擎需要访问更多的记录数，自然就会访问更多的数据量，也就是说需要更高的IO 成本。 可能有些朋友会说，那我们可以通过创建多个单键索引啊。确实，我们可以将WHERE 子句中的每一 个字段都创建一个单键索引。但是这样真的有效吗？在这样的情况下，MySQL Query Optimizer 大多数 时候都只会选择其中的一个索引，然后放弃其他的索引。即使他选择了同时利用两个或者更多的索引通 过INDEX_MERGE 来优化查询，可能所收到的效果并不会比选择其中某一个单键索引更高效。因为如果选 择通过INDEX_MERGE 来优化查询，就需要访问多个索引，同时还要将通过访问到的几个索引进行merge 操作，所带来的成本可能反而会比选择其中一个最有效的索引来完成查询更高。 在一般的应用场景中，只要不是其中某个过滤字段在大多数场景下都能过滤出90%以上的数据，而且 其他的过滤字段会存在频繁的更新，我一般更倾向于创建组合索引，尤其是在并发量较高的场景下更是 应该如此。因为当我们的并发量较高的时候，即使我们为每个Query 节省很少的IO 消耗，但因为执行 量非常大，所节省的资源总量仍然是非常可观的。 当然，我们创建组合索引并不是说就需要将查询条件中的所有字段都放在一个索引中，我们还应该 尽量让一个索引被多个Query 语句所利用，尽量减少同一个表上面索引的数量，减少因为数据更新所带 来的索引更新成本，同时还可以减少因为索引所消耗的存储空间。 此外，MySQL 还为我们提供了一个减少优化索引自身的功能，那就是前缀索引。在MySQL 中，我们 可以仅仅使用某个字段的前面部分内容做为索引键来索引该字段，来达到减小索引占用的存储空间和提 高索引访问的效率。当然，前缀索引的功能仅仅适用于字段前缀比较随机重复性很小的字段。如果我们 需要索引的字段的前缀内容有较多的重复，索引的过滤性自然也会随之降低，通过索引所访问的数据量 就会增加，这时候前缀索引虽然能够减少存储空间消耗，但是可能会造成Query 访问效率的极大降低， 反而得不偿失。 Query 的索引选择 在有些场景下，我们的Query 由于存在多个过滤条件，而这多个过滤条件可能会存在于两个或者更 多的索引中。在这种场景下，MySQL Query Optimizer 一般情况下都能够根据系统的统计信息选择出一 个针对该Query 最优的索引完成查询，但是在有些情况下，可能是由于我们的系统统计信息的不够准确 完整，也可能是MySQL Query Optimizer 自身功能的缺陷，会造成他并没有选择一个真正最优的索引而 选择了其他查询效率较低的索引。在这种时候，我们就不得不通过认为干预，在Query 中增加Hint 提 示MySQL Query Optimizer 告诉他该使用哪个索引而不该使用哪个索引，或者通过调整查询条件来达到 相同的目的。 我们这里再次通过在本章第2 节“Query 语句优化基本思路和原则”的“仅仅使用最有效的过滤条 件”中示例的基础上将group_message 表的索引做部分调整，然后再进行分析。 在group_message 上增加如下索引：
create index group_message_author_subject on group_message(author,subject(16)); 从索引的Sub_part 中，我们可以看到subject 字段是取前16 个字符的前缀作为索引键。下面假设 我们知道某个用户的user_id ，nick_name 和subject 字段的部分前缀信息（weiurazs），希望通过 这些条件查询出所有满足上面存在于group_message 中的信息。我们知道存在三个索引可以被利用： idx_group_message_author ， idx_group_message_uid 和group_message_author_subject，而且也知 道每个user_id 实际上都是和一个author 分别唯一对应的。所以实际上，无论是使用user_id 和 author（nick_name）中的某一个来作为条件或者两个条件都使用，所得到的数据都是完全一样的。当 然，我们还需要subject LIKE 'weiurazs%' 这个条件来过滤subject 相关的信息。 根据三个索引的组成，和我们的查询条件，我们知道group_message_author_subject 索引可以让我 们得到最高的检索效率，因为只有他索引了subject 相关的信息，subject 是我们的查询必须包含的过 滤条件。下面我们分别看看使用user_id ，author 和两者共同使用时候的执行计划。
sky@localhost : example 07:48:45> EXPLAIN SELECT * FROM group_message 很明显，这不是我们所期望的执行计划，当然我们并不能责怪MySQL，因为我们都没有使用author 来进行过滤，Optimizer 当然不会选择group_message_author_subject 这个索引，这是我们自己的 错。
sky@localhost : example 07:48:49> EXPLAIN SELECT * FROM group_message 这次我们改为使用author 作为查询条件了，可MySQL Query Optimizer 仍然没有选择 group_message_author_subject 这个索引，即使我们通过analyze 分析也是同样的结果。
sky@localhost : example 07:48:57> EXPLAIN SELECT * FROM group_message 同时使用user_id 和author 两者的时候，MySQL Query Optimizer 又再次选择了
idx_group_message_uid 这个索引，仍然不是我们期望的结果。 在最后，我们不得不利用MySQL 为我们提供的在优化Query 时候所使用的高级功能，通过显式告 诉MySQL Query Optimizer 我们要使用哪个索引的Hint 功能。强制MySQL 使用 group_message_author_subject 这个索引来完成查询，才达到我们所需要的效果。 或许有些读者会想，会不会是因为选择group_message_author_subject 这个索引本身就不是一个 最有的选择呢？大家请看下面通过mysqlslap 进行的实际执行各条Query 的测试结果：
sky@sky:~$ mysqlslap --create-schema=example --query="SELECT * FROM group_message WHERE 我们可以清晰的看出，通过我们添加Hint 之后选择group_message_author_subject 这个索引的 Query 确实比其他的三条要快很多。 通过这个示例，我们可以看出在优化Query 的时候，选择合适的索引是非常重要的，而且我们也同 时实例证明了MySQL Query Optimizer 并不是任何时候都能够选择出最佳的执行计划，在有些时候，我 们不得不通过人为的手工干预来让MySQL Query Optimizer 改变他的“想法”，而按照我们的思路走。 当然，这个示例仅仅只是告诉了我们选择合适索引的重要性，并且不能任何时候都完全相信MySQL Query Optimizer，但并没有告诉我们到底该如何来选择一个更合适的索引。下面是我对于选择合适索引 的几点建议，并不一定在任何场景下都合适，但在大多数场景下还是比较适用的。
Hint 人为控制索引的选择，因为这会使后期的维护成本增加，同时增加维护所带来的潜在风险。 MySQL 中索引的限制 在使用索引的同时，我们还应该了解在MySQL 中索引存在的限制，以便在索引应用中尽可能的避开 限制所带来的问题。下面列出了目前MySQL 中索引使用相关的限制。
(责任编辑：IT) |