MySQL中的索引优化

数据库的索引
1.
如果不建立索引，那么查询都需要全表扫描；如果建立了索引，则数据库会保存一个索引文件通常是特殊的结构比如B树，这样查询起来不需要全表扫描，一下子能够找到满足要求的记录。
2.
一般是对Where之后的条件建立索引，数据库中的主键是已经建立了索引的。数据库中可以建立多个索引。
可以对不同类型的列建立索引。
对于Text类型等，可以使用MySQL的全文检索功能建立全文索引。它利用了自然语言的方法去在文本中检索关键词。
举个例子：如果使用=号的话可能需要使用like以及%等去匹配。而使用MySQL的全文检索可以使用Match函数即可检索出包含关键词的列。

4.1使用索引
    我们首先讨论索引，因为它是加快查询的最重要的工具。还有其他加快查询的技术，但是最有效的莫过于恰当地使用索引了。在MySQL的邮件清单上，人们通常 询问关于使查询更快的问题。在大量的案例中，都是因为表上没有索引，一般只要加上索引就可以立即解决问题。但这样也并非总是有效，因为优化并非总是那样简 单。然而，如果不使用索引，在许多情形下，用其他手段改善性能只会是浪费时间。应该首先考虑使用索引取得最大的性能改善，然后再寻求其他可能有帮助的技 术。
    本节介绍索引是什么、它怎样改善查询性能、索引在什么情况下可能会降低性能，以及怎样为表选择索引。下一节，我们将讨论MySQL的查询优化程序。除了知 道怎样创建索引外，了解一些优化程序的知识也是有好处的，因为这样可以更好地利用所创建的索引。某些编写查询的方法实际上会妨碍索引的效果，应该避免这种 情况出现。（虽然并非总会这样。有时也会希望忽略优化程序的作用。我们也将介绍这些情况。）
    4.1.1索引的益处
    让我们从一个无索引的表着手来考察索引是怎样起作用的。无索引的表就是一个无序的行集。因此如果我们查找某个特定的行时，必须查看表中的每一行，看它是否与所需的值匹配。这是一个全表扫描，很慢，如果表中只有少数 几个记录与搜索条件相匹配，则其效率是相当低的。
在执行涉及多个表的连接查询时，索引甚至会更有价值。在单个 表的查询中，每列需要查看的值的数目就是表中行的数目。而在多个表的查询中，可能的组合数目极大，因为这个数目为各表中行数之积。
  　 假如有三个未索引的表t 1、t 2、t 3，分别只包含列c 1、c 2、c 3，每个表分别由含有数值1到1000 的1000 行组成。查找对应值相等的表行组合的查询如下所示：
    SELECT c1,c2,c3
    FROM t1,t2,t3
    WHERE c1=c2 AND c1=c3
    此查询的结果应该为1000 行，每个组合包含3 个相等的值。如果我们在无索引的情况下处理此查询，则不可能知道哪些行包含那些值。因此，必须寻找出所有组合以便得出与WHERE 子句相配的那些组合。可能的组合数目为10 0 0㗱0 0 0㗱0 0 0（十亿），比匹配数目多一百万倍。很多工作都浪费了，并且这个查询将会非常慢，即使在如像MySQL这样快的数据库中执行也会很慢。而这还是每个表中只 有1000 行的情形。如果每个表中有一百万行时，将会怎样？很显然，这样将会产生性能极为低下的结果。如果对每个表进行索引，就能极大地加速查询进程，因为利用索引 的查询处理如下：
    1) 如下从表t1中选择第一行，查看此行所包含的值。
    2) 使用表t2 上的索引，直接跳到t2 中与来自t1的值匹配的行。类似，利用表t3 上的索引，直接跳到t3 中与来自t1的值匹配的行。
    3) 进到表t1的下一行并重复前面的过程直到t1中所有的行已经查过。在此情形下，我们仍然对表t1执行了一个完全扫描，但能够在表t2 和t3 上进行索引查找直接取出这些表中的行。从道理上说，这时的查询比未用索引时要快一百万倍。如上所述，MySQL利用索引加速了WHERE 子句中与条件相配的行的搜索，或者说在执行连接时加快了与其他表中的行匹配的行的搜索。它也利用索引来改进其他操作的性能：
    ■ 在使用MIN( ) 和MAX( ) 函数时，能够快速找到索引列的最小或最大值。
    ■ MySQL常常能够利用索引来完成ORDER BY 子句的排序操作。
    ■ 有时，MySQL可避免对整个数据文件的读取。假如从一个索引数值列中选择值，而且不选择表中其他列。这时，通过对索引值的读取，就已经得到了读取数据文件所要得到的值。没有对相同的值进行两次读取的必要，因此，甚至无需涉及数据文件。
    4.1.2 索引的弊端
    一般情况下，如果MySQL能够知道怎样用索引来更快地处理查询，它就会这样做。这表示，在大多数情况下，如果您不对表进行索引，则损害的是您自己的利益。可以看出，作者描绘了索引的诸多好处。但有不利之处吗？是的，有。实际上，这些缺点被优点所掩盖了，
但应该对它们有所了解。
    首先，索引文件要占磁盘空间。如果有大量的索引，索引文件可能会比数据文件更快地达到最大的文件尺寸。其次，索引文件加快了检索，但增加了插入和删除，以 及更新索引列中的值的时间（即，降低了大多数涉及写入的操作的时间），因为写操作不仅涉及数据行，而且还常常涉及索引。一个表拥有的索引越多，则写操作的 平均性能下降就越大。在4 . 4节“有效地装载数据”中，我们将更为详细地介绍这些性能问题，并讨论怎样解决。
    4.1.3 选择索引
    创建索引的语法已经在3 . 4 . 3节“创建和删除索引”中进行了介绍。这里，我们假定您已经阅读过该节。但是知道语法并不能帮助确定表怎样进行索引。要决定表怎样进行索引需要考虑表的使用方式。本节介绍一些关于怎样确定和挑选索引列的准则：
    ■ 搜索的索引列，不一定是所要选择的列。换句话说，最适合索引的列是出现在WHERE 子句中的列，或连接子句中指定的列，而不是出现在SELECT 关键字后的选择列表中的列。
当然，所选择的列和用于WHERE 子句的列也可能是相同的。关键是，列出现在选择列表中不是该列应该索引的标志。出现在连接子句中的列或出现在形如col1= col2 的表达式中的列是很适合索引的列。查询中的col_b 和col_c 就是这样的例子。如果MySQL能利用连接列来优化一个查询，表示它通过消除全表扫描相当可观地减少了表行的组合。
    ■ 使用惟一索引。考虑某列中值的分布。对于惟一值的列，索引的效果最好，而具有多个重复值的列，其索引效果最差。例如，存放年龄的列具有不同值，很容易区分 各行。而用来记录性别的列，只含有“ M”和“F”，则对此列进行索引没有多大用处（不管搜索哪个值，都会得出大约一半的行）。
    ■ 使用短索引。如果对串列进行索引，应该指定一个前缀长度，只要有可能就应该这样做。例如，如果有一个CHAR(200) 列，如果在前10 个或20 个字符内，多数值是惟一的，那么就不要对整个列进行索引。对前10 个或20 个字符进行索引能够节省大量索引空间，也可能会使查询更快。较小的索引涉及的磁盘I/O 较少，较短的值比较起来更快。更为重要的是，对于较短的键值，索引高速缓存中的块能容纳更多的键值，因此，MySQL也可以在内存中容纳更多的值。这增加 了找到行而不用读取索引中较多块的可能性。（当然，应该利用一些常识。如仅用列值的第一个字符进行索引是不可能有多大好处的，因为这个索引中不会有许多不 同的值。）
    ■ 利用最左前缀。在创建一个n 列的索引时，实际是创建了MySQL可利用的n 个索引。多列索引可起几个索引的作用，因为可利用索引中最左边的列集来匹配行。这样的列集称为最左前缀。（这与索引一个列的前缀不同，索引一个列的前缀是 利用该的前n 个字符作为索引值。）
    假如一个表在分别名为s t a t e、city 和zip 的三个列上有一个索引。索引中的行是按state/city/zip 的次序存放的，因此，索引中的行也会自动按state/city 的顺序和state 的顺序存放。这表示，即使在查询中只指定state 值或只指定state 和city 的值，MySQL也可以利用索引。因此，此索引可用来搜索下列的列组合：
    state,city,zip
    state,city
    sate
    MySQL不能使用不涉及左前缀的搜索。例如，如果按city 或zip 进行搜索，则不能使用该索引。如果要搜索某个州以及某个zip 代码（索引中的列1和列3），则此索引不能用于相应值的组合。但是，可利用索引来寻找与该州相符的行，以减少搜索范围。
    ■ 不要过度索引。不要以为索引“越多越好”，什么东西都用索引是错的。每个额外的索引都要占用额外的磁盘空间，并降低写操作的性能，这一点我们前面已经介绍 过。在修改表的内容时，索引必须进行更新，有时可能需要重构，因此，索引越多，所花的时间越长。如果有一个索引很少利用或从不使用，那么会不必要地减缓表 的修改速度。此外，MySQL在生成一个执行计划时，要考虑各个索引，这也要费时间。创建多余的索引给查询优化带来了更多的工作。索引太多，也可能会使 MySQL选择不到所要使用的最好索引。只保持所需的索引有利于查询优化。如果想给已索引的表增加索引，应该考虑所要增加的索引是否是现有多列索引的最左 索引。如果是，则就不要费力去增加这个索引了，因为已经有了。
    ■ 考虑在列上进行的比较类型。索引可用于“ <”、“ < = ”、“ = ”、“ > =”、“ > ”和BETWEEN 运算。在模式具有一个直接量前缀时，索引也用于LIKE 运算。如果只将某个列用于其他类型的运算时（如STRCMP( )），对其进行索引没有价值。