关于如何确定要索引的数据列以及如何正确的建立索引的一些方法

尽量为用来搜索，分类或分组的数据列编制索引，不要为作为输出显示的数据列编制索引。换句话说，最适合有索引的数据是那些在where字句中出现的数据列，在联结子句中给出的数据列，或者是在order by 或group by字句中出现的数据列，根据select关键字仅出现在输出数据列清单里的数据列最好不要有索引：
SELECT
  col_a    <--  not a candidate
        FROM
  tbll LEFT JOIN tbl2
ON  tbll.col_b = tbl2.col_c  <-- candidates
WHERE
         col_d=expr;           <-- a candidate
当然，你显示的数据列和在WHERE子句中使用的数据列可能会一样，问题在于输出数据列表单中出现的数据列本身并不能说明它应该有索引。
      出现在联结子句中的数据列，或者WHERE子句中col1=col2格式的表达式里的数据列特别适合用于索引。上面查询中给出的col_b和col_c就是这样的列子，如果MYSQL能够使用相联结的数据列来优化查询，它就不会使用全数据表扫描，这样能删除掉大量潜在的数据表-数据行组合。
综合考虑各数据列的维度势。数据列的“维度”等于它所容纳的非重复值得个数。比如说，如果某个数据列里的值分别是1,3,7,4,7,3.它的维度就是4，数据列的维度越高（维度的最大值等于数据表里的数据行的个数）。它包含的独一无二的值就越多。重复的值就越少。索引使用的效果也就越好。举例来看。如果一个数据列包含许多不同的年龄值，索引将迅速的将数据行区分开来，但是对于记录性别的数据列，其中只有2个值“M”和“F”，索引恐怕就帮不了你了，如果这2个值出现情况大致一样多，那么不管你搜索的是哪一个值，你都会得到半数左右的数据行，在这种情况下，索引或许就根本不能够使用，因为当查询优化程序确定出某一个数值在数据表的数据行中出现频率超过30%时，查询优化程序通常会跳过索引，而进行全数据表扫描，现如今的优化器更复杂，能够把其他因素也考虑进来，所以这个百分比已经不再是MySQL决定进行一次扫描而不是使用一个索引的唯一依据了。
对短小的值进行索引。应该尽量选用比较“小”的数据类型，比如说，如果一个MEDIUMINT数据列已足以容纳你需要存储的数据，就不要选用BIGINT,如果你的数据没有一个比25个字符更长，就不要选用CHAR(100),比较短小的值可以在以下几个方面提高索引的处理性能
 1）短小的值可以让比较操作更快地完成，加快索引查找速度
 2）短小的值可以让索引的“体积”更小，减少磁盘I/O活动
 3）短小的键值意味着键缓存里的索引块可以容纳更多的键值，让mysql可以在内存里同时容纳更多的键，而这将加大在不需要从磁盘读取更多索引块的前提下在内存里找到键值的概率，对InnoDB存储引擎而言，因为它使用的是聚集索引，所以让主键尽量短小将更有好处。所谓“聚集索引”（clustered index）是指把数据行和主键值集中保存在一起的情况，其他的索引都是些二级索引-它们保存着主键值和二级索引值，先在二级索引里找到一个主键值，再通过它找到相应的数据行，这意味着主键值在每一个二级索引里都不会重复出现，如果主键值比较长的话，就会导致每一个二级索引都将需要占用更多的存储空间。
为字符串值的前缀编索引。假如你要为字符串数据列编索引，应当尽可能给出前缀长度，例如你有一个char(200)的数据列，大多值的前10个或20个字符都是唯一的，那么你就用不着为整个数据列编索引，仅仅为前面20个或30个字符编索引可以节省索引中大量空间，而且会使用查询进行得更快，为较小的值编排索引可以减少磁盘的输入输出，加快比较速度，当然你会想继续使用一些惯常的做法，但只为第一个字符编索引恐怕不行，因为这样一来索引中将不会有太多的唯一的值
充分利用最左边的前缀 当你创建了一个N个数据列的复合索引时，实际上就创建了mysql能够使用的n个索引，一个复合索引在工作是就相当于n个索引，因为索引中最左边的数据列集合能够用于匹配数据行，这样的一个集合就称为“最左边的前缀”（这和为数据列的前缀编索引时不同的，它是将数据列的前N个字符或字节作为索引值）
适合而止，不要建立过多的索引。不要以为索引越多越好，不要为你看到的所有东西都来编排索引，这是一种错误的做法，如上所述，每一个多出的索引都要占据额外的磁盘空间，而且都会影响写入操作的性能，当你修改了数据表的内容后，索引必须要更新以及重新编排，你使用的索引越多，这个过程占据的时间就越长，如果你有一个很少使用或从没有使用过的索引，你就无谓地降低了数据表修改的速度。此外，MySQL在为检索生产一个执行方案时都要仔细对索引进行推敲，创建多余的索引对查询优化程序就加上了更多的工作，而且，当你有太多索引时，MySQL还有可能（当然这只是一种可能）无法选出最好的索引来使用，仅保留你需要的索引可以帮助查询优化程序来避免造成这样的错误
让索引的类型和你打算进行得比较操作的类型保持匹配。在创建索引的时候，绝大多数存储引擎会选择它们将使用的索引实现
利用“慢查询”日志找到性能低劣的查询