所有的MySQL列类型能被索引。在相关的列上的使用索引是改进SELECT操作性能的最好方法。
一个表最多可有16个索引。最大索引长度是256个字节，尽管这可以在编译MySQL时被改变。
对于CHAR和VARCHAR列，你可以索引列的前缀。这更快并且比索引整个列需要较少的磁盘空间。在CREATE TABLE语句中索引列前缀的语法看起来像这样：
KEY index_name (col_name(length))
下面的例子为name列的头10个字符创建一个索引：
mysql> CREATE TABLE test (
name CHAR(200) NOT NULL,
KEY index_name (name(10)));
对于BLOB和TEXT列，你必须索引列的前缀，你不能索引列的全部。
多列索引
MySQL能在多个列上创建索引。一个索引可以由最多15个列组成。（在CHAR和VARCHAR列上，你也可以使用列的前缀作为一个索引的部分)。
一个多重列索引可以认为是包含通过合并(concatenate)索引列值创建的值的一个排序数组。
当你为在一个WHERE子句索引的第一列指定已知的数量时，MySQL以这种方式使用多重列索引使得查询非常快速，即使你不为其他列指定值。
假定一张表使用下列说明创建：
mysql> CREATE TABLE test (
id INT NOT NULL,
last_name CHAR(30) NOT NULL,
first_name CHAR(30) NOT NULL,
PRIMARY KEY (id),
INDEX name (last_name,first_name));
那么索引name是一个在last_name和first_name上的索引，这个索引将被用于在last_name或last_name和first_name的一个已知范围内指定值的查询，因此，name索引将使用在下列查询中：
mysql> SELECT * FROM test WHERE last_name=”Widenius”;
mysql> SELECT * FROM test WHERE last_name=”Widenius”
AND first_name=”Michael”;
mysql> SELECT * FROM test WHERE last_name=”Widenius”
AND (first_name=”Michael” OR first_name=”Monty”);
mysql> SELECT * FROM test WHERE last_name=”Widenius”
AND first_name >=”M” AND first_name < "N";
然而，name索引将不用在下列询问中：
mysql> SELECT * FROM test WHERE first_name=”Michael”;
mysql> SELECT * FROM test WHERE last_name=”Widenius”
OR first_name=”Michael”;
以下小故事摘在互联网：
网站系统上线至今，数据量已经不知不觉上到500M，近8W记录了。涉及数据库操作的基本都是变得很慢了，用的人都会觉得躁火~~然后把这个情况在群里一贴，包括机器配置什么的一说，马上就有群友发话了，而且帮我确定了不是机器配置的问题，“深圳-枪手”热心人他的机器512内存过百W的数据里也跑得飞快，甚至跟那些几W块的机器一样牛(吹过头了)，呵呵~~~
在群友的分析指点下，尝试把排序、条件等一个一个去除来做测试，结果发现问题就出在排序部分，去除排序的时候，执行时间由原来的48秒变成0.3x秒，这是个什么档次的变化呀~~看着这个结果我激动ing.....
于是我把涉及排序的字段组成一个联合索引alter table xx add index indexname(x1,x2,x3)，经过2分钟创建新索引之后再执行同一个SQL语句，哇塞0.28S。。。。爽
于是按照同样的思路把其它几个常用的SQL作了过些优化，效果马上见效
过了30分钟再查slow sql记录文件，不好了，发现原来一个好好的SQL变得灰常慢了，神马情况?
几经分析和测试原来就是因为添加了联合索引的原因，而且这个SQL语句当中有个or，当把这个or改用union之后问题排除。
这回又得出一个心得：写SQL的时候千万别一时就手，随便写个就OK，那会为以为带来很严重的后果。
再附上一段关于Where子句的执行顺序：
在用MySQL查询数据库的时候，连接了很多个用，发现非常慢。例如：
SELECT ... WHERE p.languages_id = 1 AND m.languages_id = 1 AND c.languages_id = 1 AND t.languages_id = 1 AND p.products_id IN (472,474)
这样查询需要20多秒，虽然在各个字段上都建立了索引。用分析Explain SQL一分析，发现在第一次分析过程中就返回了几万条数据：
WHERE p.languages_id = 1 ，然后再依次根据条件，缩小范围。
而我改变一下WHERE 字段的位置之后，速度就有了明显地提高：
WHERE p.products_id IN (472,474) AND p.languages_id = 1 AND m.languages_id = 1 AND c.languages_id = 1 AND t.languages_id = 1
这样，第一次的条件是p.products_id IN (472,474)，它返回的结果只有不到10条，接下来还要根据其它的条件来过滤，自然在速度上有了较大的提升。
经过实践发现，不要以为WHERE中的字段顺序无所谓，可以随便放在哪，应该尽可能地第一次就过滤掉大部分无用的数据，只返回最小范围的数据。
网站系统上线至今，数据量已经不知不觉上到500M，近8W记录了。涉及数据库操作的基本都是变得很慢了，用的人都会觉得躁火~~然后把这个情况在群里一贴，包括机器配置什么的一说，马上就有群友发话了，而且帮我确定了不是机器配置的问题，“深圳-枪手”热心人他的机器512内存过百W的数据里也跑得飞快，甚至跟那些几W块的机器一样牛(吹过头了)，呵呵~~~
在群友的分析指点下，尝试把排序、条件等一个一个去除来做测试，结果发现问题就出在排序部分，去除排序的时候，执行时间由原来的48秒变成0.3x秒，这是个什么档次的变化呀~~看着这个结果我激动ing.....
于是我把涉及排序的字段组成一个联合索引alter table xx add index indexname(x1,x2,x3)，经过2分钟创建新索引之后再执行同一个SQL语句，哇塞0.28S。。。。爽
于是按照同样的思路把其它几个常用的SQL作了过些优化，效果马上见效
过了30分钟再查slow sql记录文件，不好了，发现原来一个好好的SQL变得灰常慢了，神马情况?
几经分析和测试原来就是因为添加了联合索引的原因，而且这个SQL语句当中有个or，当把这个or改用union之后问题排除。
这回又得出一个心得：写SQL的时候千万别一时就手，随便写个就OK，那会为以为带来很严重的后果。
再附上一段关于Where子句的执行顺序：
在用MySQL查询数据库的时候，连接了很多个用，发现非常慢。例如：
SELECT ... WHERE p.languages_id = 1 AND m.languages_id = 1 AND c.languages_id = 1 AND t.languages_id = 1 AND p.products_id IN (472,474)
这样查询需要20多秒，虽然在各个字段上都建立了索引。用分析Explain SQL一分析，发现在第一次分析过程中就返回了几万条数据：
WHERE p.languages_id = 1 ，然后再依次根据条件，缩小范围。
而我改变一下WHERE 字段的位置之后，速度就有了明显地提高：
WHERE p.products_id IN (472,474) AND p.languages_id = 1 AND m.languages_id = 1 AND c.languages_id = 1 AND t.languages_id = 1
这样，第一次的条件是p.products_id IN (472,474)，它返回的结果只有不到10条，接下来还要根据其它的条件来过滤，自然在速度上有了较大的提升。
经过实践发现，不要以为WHERE中的字段顺序无所谓，可以随便放在哪，应该尽可能地第一次就过滤掉大部分无用的数据，只返回最小范围的数据。