MySQL5.0中索引的设计和使用
下面讨论下MySQL5.0中的索引的设计和使用。任何东西设计的好，那么使用起来就顺手。不过很多时候给出设计什么规则这些都是相对的。做任何的事情，最重要的是能否根据当时情况就合理的调整你的设计。如果你只会看着书本或者权威来死套什么设计理念来进行实际的开发和设计的话，那么我请你还是少读书为妙。
索引是数据库中用来提高性能的常用工具。（注意如果要优化数据库的性能，这是一个点）。
所有MySQL列类型都可以被索引，对相关列使用索引是提高SELECT操作性能的最佳途径。根据存储引擎可以定义每个表的最大索引数和最大索引长度，每种存储引擎(MyISAM、InnoDB、BDB、MEMORY等)对每个表至少支持16个索引，总索引长度至少为256字节。大多数存储引擎有更高的限制。
MyISAM和InnoDB存储引擎的表默认创建的都是BTREE索引。MySQL目前还不支持函数索引，但是支持前缀索引，即对索引字段的前N个字符创建索引。前缀索引的长度跟存储引擎相关，对于MyISAM存储引擎的表，索引的前缀长度可以达到1000字节长，而对于Inn0DB存储引擎的表，索引的前缀长度最长是767字节。请注意前缀的限制应以字节为单位进行测量，而CREATE TABLE语句中的前缀长度解释为字符数。在为使用多字节字符集的列指定前缀长度时一定要加以考虑。
MySQL中还支持全文本索引（FULLTEXT），该索引可以用于全文搜索。但是在Mysql5.0中只有MyISAM存储引擎支持全文本索引，并且仅仅局限于CHAR、VARCHAR和TEXT列。索引总是对整个列进行的，不支持局部索引。也可以为空间类型创建索引，但是只要MyISAM存储引擎支持空间类型索引，而且索引的字段必须是非空。
创建索引的语法如下：
引用
CREATE [UNIQUE | FULLTEXT | SPATIAL] IDEX index_name
[USING index_type]
ON tb1_name (index_col_name,....)
index_col_name:
col_name [(length)][ASC | DESC]
索引的创建可以在创建表的时候就创建，也可以随时增加新的索引。
下面给出一个例子：
引用
create index personname on person (person(10))
查询,可以发现索引personname被使用
引用
explain select * from person where person='hi' \G
索引的删除语法为：
引用
DROP INDEX index_name ON tb1_name
如果想删除person表中的personname索引如下操作
引用
drop index personname on person
上面简单的演示了索引的创建和删除。
接下来讨论下索引的设计原则：
索引的设计可以遵循一些已有的原则，创建索引的时候请尽量考虑符合这些原则，便于提升索引的使用效率，更高效地使用索引。
1. 搜索的索引列，不一定是所要选择的列。最合适索引的列是出现在WHERE子句中的列，或连接子句中指定的列，而不是出现在SELECT关键字后的选择列表中的列。
2. 使用唯一索引。考虑某列中值的分布。索引的列的基数越大，索引的效果越好。例如数据库中有好几年的资料，这些资料中有日期这个字段，而且查询中常常要区分日期。那么针对日期设索引就很容易区分。
3. 使用短索引。如果对字符串列进行索引，应该指定前缀长度，只要有可能就应该这样做。例如：如果有一个CHAR(200)的列，如果在前10个或20个字符内，多数值是唯一的。那么就不要对整个列进行索引。对前10个或者20个字符进行索引能够节省大量索引空间，也可能会使查询更快。较小的索引涉及的磁盘IO较少，较短的值比较起来更快。更为重要的是，对于较短的键值，索引高速缓存中的块能容纳更多的键值，因此,MySQL也可以在内存中容纳更多的值。这样就增加了找到行而不用读取索引中较多块的可能性。
4.利用最左前缀。在创建一个n列的索引时，实际是创建了MySQL可利用的n个索引。多列索引起几个索引的作用，因为可利用索引中最左的列集来匹配行。这样的列集称最左前缀。
5. 不要过度索引。不要以为索引“越多越好”，什么东西都用索引是错误的。每个额外的索引都要占用额外的磁盘空间，并降低写操作的性能。在修改表的内容时，索引必须进行更新，有时可能需要重构，因此，索引越多，所花的时间越
长。如果有一个索引很少利用或者从不使用，那么会不必要地减缓表的修改速度。此为MySQL在生成一个执行计划时，要考虑各个索引，这也要花费时间。创建多余的索引给查询优化带来了更多的工作。索引太多，也可能会使MySQL选择不到所要使用的最好索引。值保持所需的索引有利于查询优化。
6. 对于InnoDB存储引擎的表，记录默认会按照一个的顺序保存，如果有明确定义的主键，则按照主键顺序保存。如果没有主键，但是有唯一索引，那么就是按照唯一索引的顺序保存。如果既没有主键有没有唯一索引，那么表中会自动生成一个内部列，按照这个列的顺序保存。按照主键或者内部列进行的访问是最快的，所以InnoDB表尽量自己指定主键，当表中同时有几个列都是唯一的，都可以作为主键的时候，要选择最常作为访问条件的列作为主键，提高查询的效率。另外还需要注意，InnoDB表的普通索引都会保存主键的键值，所以主键要尽可能选择较短的数据类型，可以有效减少索引的磁盘占用，提高索引的缓存效果。
BTREE索引与HASH索引
MEMORY存储引擎的表可以选择使用BTREE或者HASH索引，两种不同类型的索引各有其不同的适用范围。HASH索引有些重要的特征需要在使用的时候特别注意，如下所示：
1. 只用于使用=或<=>操作符的等式比较。
2. 优化器不能使用HASH索引来加速ORDER BY操作
3. MySQL不能确定在两个值之间大约有多少行。如果将一个MyISAM表改为HASH索引的MEMORY表，会影响一些查询的执行效率。
4. 只能使用整个关键字来搜索一行。
而对于BTREE索引，当使用 > 、< 、>= 、<= 、BETWEEN 、!= 或者 <> ,或者LINKE'pattern'（其中'pattern'不以通配符开始）操作符时，都可以使用相关列上的索引。
索引的类型和使用场合
索引分单列索引和组合索引
单列索引：即一个索引只包含单个列，一个表可以有多个单列索引，但这不是组合索引。
组合索引：即一个索包含多个列。
介绍一下索引的类型
1.普通索引。
这是最基本的索引，它没有任何限制。它有以下几种创建方式：
（1）创建索引：CREATE INDEX indexName ON
tableName(tableColumns(length));如果是CHAR,VARCHAR类型，length可以小于字段实际长度;如果是BLOB 和 TEXT 类型，必须指定length，下同。
（2）修改表结构：ALTER tableName ADD INDEX [indexName] ON (tableColumns(length))
（3）创建表的时候直接指定：CREATE TABLE tableName ( [...], INDEX
[indexName] (tableColumns(length)) ;
2.唯一索引。
它与前面的"普通索引"类似，不同的就是：索引列的值必须唯一，但允许有空值。如果是组合索引，则列值的组合必须唯一。它有以下几种创建方式：
（1）创建索引：CREATE UNIQUE INDEX indexName ON
tableName(tableColumns(length))
（2）修改表结构：ALTER tableName ADD UNIQUE [indexName] ON (tableColumns(length))
（3）创建表的时候直接指定：CREATE TABLE tableName ( [...], UNIQUE
[indexName] (tableColumns(length));
3.主键索引
它是一种特殊的唯一索引，不允许有空值。一般是在建表的时候同时创建主键索引：CREATE TABLE testIndex(i_testID INT NOT NULL
AUTO_INCREMENT,vc_Name VARCHAR(16) NOT NULL,PRIMARY KEY(i_testID)); 当然也可以用ALTER命令。
记住：一个表只能有一个主键。
4.全文索引
MySQL从3.23.23版开始支持全文索引和全文检索。这里不作讨论，呵呵~~
删除索引的语法：DROP INDEX index_name ON tableName
单列索引和组合索引
为了形象地对比两者，再建一个表：
CREATE TABLE myIndex ( i_testID INT NOT NULL AUTO_INCREMENT, vc_Name VARCHAR(50) NOT NULL, vc_City VARCHAR(50) NOT NULL, i_Age INT NOT NULL, i_SchoolID INT NOT NULL, PRIMARY KEY (i_testID) );
在这10000条记录里面7上8下地分布了5条vc_Name="erquan"的记录，只不过city,age,school的组合各不相同。
来看这条T-SQL：
SELECT i_testID FROM myIndex WHERE vc_Name='erquan' AND vc_City='郑州' AND i_Age=25;
首先考虑建单列索引：
在vc_Name列上建立了索引。执行T-SQL时，MYSQL很快将目标锁定在了
vc_Name=erquan的5条记录上，取出来放到一中间结果集。在这个结果集里，先排除掉vc_City不等于"郑州"的记录，再排除i_Age不等于25的记录，最后筛选出唯一的符合条件的记录。
虽然在vc_Name上建立了索引，查询时MYSQL不用扫描整张表，效率有所提高，但离我们的要求还有一定的距离。同样的，在vc_City和i_Age分别建立的单列索引的效率相似。
为了进一步榨取MySQL的效率，就要考虑建立组合索引。就是将
vc_Name,vc_City,i_Age建到一个索引里：
ALTER TABLE myIndex ADD INDEX name_city_age
(vc_Name(10),vc_City,i_Age);--注意了，建表时，vc_Name长度为50，这里为什么用10呢？因为一般情况下名字的长度不会超过10，这样会加速索引查询速度，还会减少索引文件的大小，提高INSERT的更新速度。
执行T-SQL时，MySQL无须扫描任何记录就到找到唯一的记录！！
肯定有人要问了，如果分别在vc_Name,vc_City,i_Age上建立单列索引，让该表有3个单列索引，查询时和上述的组合索引效率一样吧？嘿嘿，大不一样，远远低于我们的组合索引~~虽然此时有了三个索引，但MySQL只能用到其中的那个它认为似乎是最有效率的单列索引。
建立这样的组合索引，其实是相当于分别建立了
vc_Name,vc_City,i_Age
vc_Name,vc_City
vc_Name
这样的三个组合索引！为什么没有vc_City,i_Age等这样的组合索引呢？这是因为mysql组合索引"最左前缀"的结果。简单的理解就是只从最左面的开始组合。并不是只要包含这三列的查询都会用到该组合索引，下面的几个T-SQL会用到：
SELECT * FROM myIndex WHREE vc_Name="erquan" AND vc_City="郑州" SELECT * FROM myIndex WHREE vc_Name="erquan"
而下面几个则不会用到：
SELECT * FROM myIndex WHREE i_Age=20 AND vc_City="郑州"
SELECT * FROM myIndex WHREE vc_City="郑州"
使用索引
到此你应该会建立、使用索引了吧？但什么情况下需要建立索引呢？一般来说，在WHERE和JOIN中出现的列需要建立索引，但也不完全如此，因为MySQL只对 <，<=，=，>，>=，BETWEEN，IN，以及某些时候的LIKE(后面有说明)才会使用索引。
SELECT t.vc_Name FROM testIndex t LEFT JOIN myIndex m ON
t.vc_Name=m.vc_Name WHERE m.i_Age=20 AND m.vc_City='郑州' 时，有对myIndex表的vc_City和i_Age建立索引的需要，由于testIndex表的vc_Name开出现在了JOIN子句中，也有对它建立索引的必要。
刚才提到了，只有某些时候的LIKE才需建立索引？是的。因为在以通配符 % 和 _ 开头作查询时，MySQL不会使用索引，如
SELECT * FROM myIndex WHERE vc_Name like'erquan%'
会使用索引，而
SELECT * FROM myIndex WHEREt vc_Name like'%erquan'
就不会使用索引了。
索引的不足之处
上面说了那么多索引的好话，它真的有像传说中那么优秀么？当然会有缺点了。
1.虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件
2.建立索引会占用磁盘空间的索引文件。一般情况这个问题不太严重，但如果你在一个大表上创建了多种组合索引，索引文件的会膨胀很快。
MySQL索引优化
写在前面：索引对查询的速度有着至关重要的影响，理解索引也是进行数据库性能调优的起点。考虑如下情况，假设数据库中一个表有10^6条记 录，DBMS的页面大小为4K，并存储100条记录。如果没有索引，查询将对整个表进行扫描，最坏的情况下，如果所有数据页都不在内存，需要读取10^4 个页面，如果这10^4个页面在磁盘上随机分布，需要进行10^4次I/O，假设磁盘每次I/O时间为10ms(忽略数据传输时间)，则总共需要 100s(但实际上要好很多很多)。如果对之建立B-Tree索引，则只需要进行log100(10^6)=3次页面读取，最坏情况下耗时30ms。这就 是索引带来的效果，很多时候，当你的应用程序进行SQL查询速度很慢时，应该想想是否可以建索引。进入正题：
1、选择索引的数据类型
MySQL支持很多数据类型，选择合适的数据类型存储数据对性能有很大的影响。通常来说，可以遵循以下一些指导原则：
(1)越小的数据类型通常更好：越小的数据类型通常在磁盘、内存和CPU缓存中都需要更少的空间，处理起来更快。
(2)简单的数据类型更好：整型数据比起字符，处理开销更小，因为字符串的比
较更复杂。在MySQL中，应该用内置的日期和时间数据类型，而不是用字符串来存储时间；以及用整型数据类型存储IP地址。
(3)尽量避免NULL：应该指定列为NOT NULL，除非你想存储NULL。在MySQL中，含有空值的列很难进行查询优化，因为它们使得索引、索引的统计信息以及比较运算更加复杂。你应该用0、一个特殊的值或者一个空串代替空值。
1.1、选择标识符
选择合适的标识符是非常重要的。选择时不仅应该考虑存储类型，而且应该考虑MySQL是怎样进行运算和比较的。一旦选定数据类型，应该保证所有相关的表都使用相同的数据类型。
(1) 整型：通常是作为标识符的最好选择，因为可以更快的处理，而且可以设置为AUTO_INCREMENT。
(2) 字符串：尽量避免使用字符串作为标识符，它们消耗更好的空间，处理起来也较慢。而且，通常来说，字符串都是随机的，所以它们在索引中的位置也是随机的，这会导致页面分裂、随机访问磁盘，聚簇索引分裂（对于使用聚簇索引的存储引擎）。
2、索引入门
对于任何DBMS，索引都是进行优化的最主要的因素。对于少量的数据，没有合适的索引影响不是很大，但是，当随着数据量的增加，性能会急剧下降。
如果对多列进行索引(组合索引)，列的顺序非常重要，MySQL仅能对索引最左边的前缀进行有效的查找。例如：
假 设存在组合索引it1c1c2(c1,c2)，查询语句select * from t1 where c1=1 and c2=2能够使用该索引。查询语句select * from t1 where c1=1也能够使用该索引。但是，查询语句select * from t1 where c2=2不能够使用该索引，因为没有组合索引的引导列，即，要想使用c2列进行查找，必需出现c1等于某值。
2.1、索引的类型
索引是在存储引擎中实现的，而不是在服务器层中实现的。所以，每种存储引擎的索引都不一定完全相同，并不是所有的存储引擎都支持所有的索引类型。
2.1.1、B-Tree索引
假设有如下一个表：
CREATE TABLE People (
last_name varchar(50) not null,
first_name varchar(50) not null,
dob date not null,
gender enum('m', 'f') not null,
key(last_name, first_name, dob)
);
其索引包含表中每一行的last_name、first_name和dob列。其结构大致如下：
索引存储的值按索引列中的顺序排列。可以利用B-Tree索引进行全关键字、关键字范围和关键字前缀查询，当然，如果想使用索引，你必须保证按索引的最左边前缀(leftmost prefix of the index)来进行查询。
(1)匹配全值(Match the full value)：对索引中的所有列都指定具体的值。例如，上图中索引可以帮助你查找出生于1960-01-01的Cuba Allen。
(2)匹配最左前缀(Match a leftmost prefix)：你可以利用索引查找last name为Allen的人，仅仅使用索引中的第1列。
(3)匹配列前缀(Match a column prefix)：例如，你可以利用索引查找last name以J开始的人，这仅仅使用索引中的第1列。
(4)匹配值的范围查询(Match a range of values)：可以利用索引查找last name在Allen和Barrymore之间的人，仅仅使用索引中第1列。
(5)匹配部分精确而其它部分进行范围匹配(Match one part exactly and match a range on another part)：可以利用索引查找last name为Allen，而first name以字母K开始的人。
(6)仅对索引进行查询(Index-only queries)：如果查询的列都位于索引中，则不需要读取元组的值。
由于B-树中的节点都是顺序存储的，所以可以利用索引进行查找(找某些值)，也可以对查询结果进行ORDER BY。当然，使用B-tree索引有以下一些限制：
(1) 查询必须从索引的最左边的列开始。关于这点已经提了很多遍了。例如你不能利用索引查找在某一天出生的人。
(2) 不能跳过某一索引列。例如，你不能利用索引查找last name为Smith且出生于某一天的人。
(3) 存储引擎不能使用索引中范围条件右边的列。例如，如果你的查询语句为WHERE last_name="Smith" AND first_name LIKE 'J%' AND dob='1976-12-23'，则该查询只会使用索引中的前两列，因为LIKE是范围查询。
2.1.2、Hash索引
MySQL 中，只有Memory存储引擎显示支持hash索引，是Memory表的默认索引类型，尽管Memory表也可以使用B-Tree索引。Memory存储 引擎支持非唯一hash索引，这在数据库领域是罕见的，如果多个值有相同的hash code，索引把它们的行指针用链表保存到同一个hash表项中。
假设创建如下一个表：
CREATE TABLE testhash (
fname VARCHAR(50) NOT NULL,
lname VARCHAR(50) NOT NULL,
KEY USING HASH(fname)
) ENGINE=MEMORY;
包含的数据如下：
假设索引使用hash函数f( )，如下：
f('Arjen') = 2323
f('Baron') = 7437
f('Peter') = 8784
f('Vadim') = 2458
此时，索引的结构大概如下：
Slots是有序的，但是记录不是有序的。当你执行
mysql> SELECT lname FROM testhash WHERE fname='Peter';
MySQL会计算’Peter’的hash值，然后通过它来查询索引的行指针。因为
f('Peter') = 8784，MySQL会在索引中查找8784，得到指向记录3的指针。 因为索引自己仅仅存储很短的值，所以，索引非常紧凑。Hash值不取决于列的数据类型，一个TINYINT列的索引与一个长字符串列的索引一样大。
Hash索引有以下一些限制：
(1)由于索引仅包含hash code和记录指针，所以，MySQL不能通过使用索引避免读取记录。但是访问内存中的记录是非常迅速的，不会对性造成太大的影响。
(2)不能使用hash索引排序。
(3)Hash索引不支持键的部分匹配，因为是通过整个索引值来计算hash值的。
(4)Hash索引只支持等值比较，例如使用=，IN( )和<=>。对于WHERE price>100并不能加速查询。
2.1.3、空间(R-Tree)索引
MyISAM支持空间索引，主要用于地理空间数据类型，例如GEOMETRY。
2.1.4、全文(Full-text)索引
全文索引是MyISAM的一个特殊索引类型，主要用于全文检索。
索引的不适用场合
表记录太少
如果一个表只有5条记录，采用索引去访问记录的话，那首先需访问索引表，再通过索引表访问数据表，一般索引表与数据表不在同一个数据块，这种情况下ORACLE至少要往返读取数据块两次。而不用索引的情况下ORACLE会将所有的数据一次读出，处理速度显然会比用索引快。
如表zl_sybm（使用部门）一般只有几条记录，除了主关键字外对任何一个字段建索引都不会产生性能优化，实际上如果对这个表进行了统计分析后ORACLE也不会用你建的索引，而是自动执行全表访问。如：
select * from zl_sybm where sydw_bh=’5401’（对sydw_bh建立索引不会产生性能优化）
经常插入、删除、修改的表
对一些经常处理的业务表应在查询允许的情况下尽量减少索引，如zl_yhbm，gc_dfss，gc_dfys，gc_fpdy等业务表。
数据重复且分布平均的表字段
假如一个表有10万行记录，有一个字段A只有T和F两种值，且每个值的分布概率大约为50%，那么对这种表A字段建索引一般不会提高数据库的查询速度。 经常和主字段一块查询但主字段索引值比较多的表字段
如gc_dfss（电费实收）表经常按收费序号、户标识编号、抄表日期、电费发生年月、操作 标志来具体查询某一笔收款的情况，如果将所有的字段都建在一个索引里那将会增加数据的修改、插入、删除时间，从实际上分析一笔收款如果按收费序号索引就已 经将记录减少到只有几条，如果再按后面的几个字段索引查询将对性能不产生太大的影响。