SQL Passion Week 6: 聚集索引
每次我们给表创建主键(Primary key)时, 默认等于一个唯一聚集索引(Unique Clustered Index). 即表示主键所包含的column是唯一的,不重复的, 同时表的物理排序也是按照主键的顺序来排列的. 同样的, 我们也列举下聚集索引的优缺点
优点
聚集表的最大好处就是数据在磁盘中是有序存储的. 我们可以将其和字典比较, 我们可以轻松的找到某个字在哪一页. 聚集索引对于查询的意义巨大, 当我们用包含在聚集索引里的column作为条件来查询数据时, SQL Server将会在查询计划中使用Clustered Index Seek操作, Seek操作非常高效, 它利用B-Tree的结构来寻找相关数据. B-Tree的时间复杂度是O(Log N), 具体细节可搜索相关资料, 这里不做展开.
在没有索引碎片的情况下, Scan操作会是一个连续IO. 索引碎片的意思是页的逻辑排序和物理排序不一致. 可以通过Index Rebuild和Index Reorganize操作来重建索引.
一个表是否容易产生索引碎片, 取决于你选择的索引列. 如果新记录是按照索引列的递增的规律不断的添加进来(比如 int identity,order date), 那么索引不会产生碎片, 因为会一直在索引的最后添加数据. 但有些少数的情况, 数据的增长没有规律性. 因此我要了解一下聚集索引的缺点, 以及错误的选择了聚集列的情况.
缺点
数据总是在聚集索引的最后插入, 这种行为我们叫做Last Page Insert Latch Contention, 这样就会在索引的最后有一个hotspot页,如图
要解决这个问题, 可以为聚集索引选择一个随机聚集键, 这样你就可以在聚集索引上分散的插入数据. 但是随机聚集键带来一个问题:Hard Page Split, SQL Server在聚集索引的页级别分配新的数据. 使用Hard Page Split会对交易日志的性能产生负面影响. 记录一个Hard Page Split要比normal insert(Soft Page Split)做更多的工作.
另一个使用随机键的副作用就是逻辑排序和物理排序不一致, 因此产生的ramdon I/O将在传统存储磁盘上降低性能. 因为在读取不同的数据页时, 磁头需要不停的做向前向后的移动.