基于Python的数据分析：数据库索引效率探究
索引在数据库中是一个很特殊的存在，它的目的就是为了提高数据查询得效率。同样，它也有弊端，更新一个带索引的表的时间比更新一个没有带索引的时间更长。有得有失。我希望做一些研究测试，搞清楚索引对于我们使用数据库有什么影响，以及如何控制这个影响。
先简单介绍两个相对立的概念：聚集索引和非聚集索引。
聚集索引根据数据行的键值在表或视图中排序和存储这些数据行。索引定义中包含聚集索引列。每个表只能有一个聚集索引，因为数据行本身只能按一个顺序排序。只有当表包含聚集索引时，表中的数据行才按排序顺序存储。如果表具有聚集索引，则该表称为聚集表。如果表没有聚集索引，则其数据行存储在一个称为堆的无序结构中。聚集索引特殊的方面是：聚集索引的叶级是实际的数据-也就是说，数据重新排序，按照和聚集索引排序条件声明的相同物理顺序存储。这意味着，一旦到达索引的叶级，就到达了数据。而非聚集索引，到达了叶级只是找到了数据的引用。因此聚集索引带来的空间消耗是需要额外的120%的空间。任何新记录都根据聚集列正确的物理顺序插入到聚集索引中。创建新页的方式随需要插入记录的位置而变化。如果新记录需要插入到索引结构中间，就会发生正常的页拆分。来自旧页的后一半记录被移到新页，并且在适当的时候，将新记录插入到新页或旧页。如果新记录在逻辑上位于索引结构的末端，那么创建新页，但是只将新记录添加到新页。在MySQL中，聚集索引可以认为是唯一索引。
非聚集索引中的项目按索引键值的顺序存储，而表中的信息按另一种顺序存储（这可以由聚集索引规定）。对于非聚集索引，可以为在表非聚集索引中查找数据时常用的每个列创建一个非聚集索引。非聚集索引中的项目按索引键值的顺序存储，而表中的信息按另一种顺序存储（这可以由聚集索引规定）。对于非聚集索引，可以为在表非聚集索引中查找数据时常用的每个列创建一个非聚集索引。在MySQL中，费聚集
引用一下网上常见的使用聚集索引和非聚集索引的使用上的注意事项：
本文并非探索索引的数据结构以及不同数据库的索引区别，对于数据分析而言也不是很重要，关键是搞懂索引的作用、索引的区别以及怎样使用索引。本文下面不再展开讨论索引的实现，对于索引结构及工作原理感兴趣的请看这篇文档http://www.cnblogs.com/kissdodog/archive/2013/06/12/3132380.html 。
测试环境和数据
不介绍测试环境的探究都是耍流氓，下面介绍一下测试所使用的环境和数据。
机器是两台IBM的PC，一台作为client，一台作为data server。PC的硬件是I5-4590CPU 3.3GHz+4GRAM（client)，I7-4790 3.6GHZ+8GRAM(server)。client和server内网连接。client是win7 32位，server是win7 64位操作系统。
测试的数据库分别是MS SQLServer 2008R2版本 和 MySQL Server5.5版本。
分别再MySQL和SQLServer的测试数据库建了三个表student_no（无索引），student_in（有非聚集索引）,student_cin（有聚集索引），表的字段都是一致的，参考下面的建表sql。
CREATE TABLE `student_xx` ( `ID` int(11) NOT NULL, `name` varchar(10) NOT NULL, `age` int(3) NOT NULL, `address` varchar(10) NOT NULL )
注意建表的过程中，我默认有几个设置，ID是所有数据都不一样的，是唯一标识符，name基本上所有人也不一样，age的数据比较一致在[20,30]这个区间，addres只记录所在省份城市的名字，数据范围在300个以内。
测试结果
测试使用的手段无非是对数据库的增删改查操作（where语句包含对应聚集索引和非聚集索引的），但是也有细分，我这里进行详细的定义。
插入操作：I1: 逐条插入，类似insert into student (ID, name,age,address) values(10000001,‘HE KEJUN’,28,’GUANGDONGG-GUANGZHOU’)，每插入100条记录并记录耗时; I2：批量插入，即10次每次进行插入100条记录。
修改操作：U1：修改某个字段;U2：修改多个字段。每修改100条记录并记录耗时
删除操作：D1：删除某条记录（含where语句）。每删除100条记录并记录耗时。
查询操作：S1：查询数据；S2：查询中带有COUNT函数；S3查询中带有SUM函数；S4查询中带有ORDER BY。上述操作都是每查询1000条记录并记录耗时。
我们首先看看在小数量级的数据中索引的不同表现。
在小数据集（数据表记录数=10000）的情况下，各个数据库操作的耗时如下：
| MSSQL | MYSQL | |||||
| 无索引 | 非聚集索引 | 聚集索引 | 无索引 | 非聚集索引 | 聚集索引 | |
| I1 | 0.80935 | 0.81045 | 0.8031 | 1.07525 | 0.782 | 0.79005 |
| I2 | 2.1868 | 2.1891 | 2.13555 | 0.15565 | 0.1688 | 0.1478 |
| D1 | 0.95685 | 0.60885 | 0.7253 | 0.9924 | 0.50565 | 0.748 |
| U1 | 0.9642 | 0.78035 | 0.7368 | 0.85725 | 0.8601 | 0.78205 |
| U2 | 0.8759 | 0.74055 | 0.70125 | 0.83575 | 0.53745 | 0.7721 |
| S1 | 3.2293 | 2.5016 | 1.92195 | 9.2856 | 2.22845 | 1.85555 |
| S2 | 2.963 | 2.051 | 2.0203 | 9.39085 | 2.2397 | 2.62835 |
| S3 | 3.1109 | 2.7788 | 2.0137 | 9.38075 | 2.26215 | 2.74975 |
| S4 | 9.6427 | 9.6553 | 7.2891 | 10.2789 | 5.9647 | 4.9492 |
在MS SQLSever中：索引不会明显影响数据库进行插入和删除操作。在大多数情况下，聚集索引的效率都比非聚集索引的高。即聚集索引在小规模数量级的数据表中是最佳选择。
同样的情况出现在MySQL数据库。
索引对于查询的耗时的降低是非常明显的。
计划在百万级的数据表中再重新设计做一次实验。
