mysql的索引

假如我们要查找年龄为13 岁的所有人员，那么可以扫描索引，结果得出前3行，当到达年龄为14的行的时候，我们发现它是一个比我们正在查找的
年龄要大的人员。
索引值是排序的，因此在读到包含14的记录时，我们知道不会再有匹配的记录，可以退出了。如果查找一个值，它在索引表中某个中间点以前不会出现，那么也有找到其第一个匹配索引项的定位算法，而不用进行表的顺序扫描（如二分查找法）。这样，可以快速定位到第一个匹配的值，以节省大量搜索时间。
可以把索引想像成汉语字典的的按笔画查找的目录。汉语字典中的汉字是按拼音的顺序排列在书页中的，如果要查询笔画数为18的汉字的话就必须挨个查找每个汉字来比较每个
汉字的笔画数，这种速度是让人无法忍受的。而如果我们创建一个按笔画查找的目录：将笔画为5 的汉字列出来，将笔画为6的汉字列出来……，
这样当我们要查询笔画数为18 的汉字的话只要来查找这个目录就可以非常快速的查找到需要的数据了。
虽然索引可以提高数据查询的速度，但是任何事物都是双刃剑，它也有一些缺点：
索引占据一定磁盘空间，就像有按笔画查找的目录的书会比没有这种目录的书页数要多一些。
索引减慢了数据插入和删除的速度。因为每次插入和删除的时候都需要更新索引，一个表拥有的索引越多，则写操作的平均性能下降就越大。
由于索引需要占据一定的存储空间，而且索引也会降低数据插入、更新和删除的速度，所以应该只创建必要的索引，一般是在检索的时候用的字段中创建索引。索引还会造成存储碎片的问题。当删除一条记录时将会导致对应的索引中的该记录的对应项为空，由于索引是采用B树结构存储的，所以对应的索引项并不会被删除，经过一段时间的增删改操作后，数据库中就会出现大量的存储碎片，这和磁盘碎片、内存碎片产生原理是类似的，这些存储碎片不仅占用了存储空间，而且降低了数据库运行的速度。如果发现索引中存在过多的存储碎片的话就要进行“碎片整理”了，最方便的
“碎片整理”手段就是重建索引，重建索引会将先前创建的索引删除然后重新创建索引，主流数据库管理系统都提供了重建索引的功能，比如REINDEX、REBUILD 等，如果使用的数据库管理系统没有提供重建索引的功能，可以首先用DROP INDEX语句删除索引，然后用ALTER TABLE 语句重新创建
索引。
表扫描和索引查找:
一般地，系统访问数据库中的数据，可以使用两种方法：全表扫描和索引查找。
全表扫描，就是指系统必须在数据表中逐条检索表中的每条记录，以检查该记录是否匹配检索条件。全表扫描有可能会造成巨大的性能损失，当然也有可能不会影响性能，这取决于表中的数据量，如果表中有上千万条甚至上亿条记录的话，全表扫描的速度会非常慢，而如果表中只有几条、几十条记录的话表扫描的性能消耗就可以忽略不计了。当表中数据量比较小的时候，使用全表扫描非常有用。但是随着表中数据量的增加，全表扫
描会导致系统性能严重下降。如果表中有索引并且待匹配条件符合索引的要求的话，DBMS 就不会执行全表扫描，而是直接到索引中查找，这将大
大加快检索的速度。DBMS 中都有查询优化器，它会根据分布的统计信息生成该查询语句的优化执行规划，以提高访问数据的效率为目标，确定是
使用全表扫描还是使用索引查找。注意并不是表中存在索引在进行检索的时候就会使用索引查找，如果使用不当检索的过程仍然会是采用全表扫描，这样索引就起不到效果了。xz
索引的语法：
创建索引：
索引是针对字段的，因此创建索引索引的时候需要指定要在那个字段上创建索引，还可以为多个字段创建一个索引，这样还可以指定索引相关
的字段列表。创建索引的SQL 语句
是CREATE INDEX，其语法如下：
CREATE INDEX 索引名ON 表名(字段1, 字段2,……字段n)
其中【索引名】为被创建的索引的名称，这个名称必须是唯一的；【表名】为要创建索引的表；【字段1,字段2,……字段n】为组成这个索引的字
段列表，允许一到多个。
删除索引：
索引创建后是可以被删除的，删除索引使用的语句为DROP INDEX。不同的数据库系统的DROP INDEX 语法是不同的，下面分别介绍：
MYSQL中的DROP INDEX 语法如下：
DROP INDEX 索引名ON 表名;比如下面的SQL语句用来删除创建了的索引：