正文

请到「今天看啥」查看全文

物理失效

物理失效就是索引真的失效了，比如被人误设了unusable动作，或者是一些类似分区表的不规范操作导致的索引失效。对此后续有详细的例子说明。

二、感受美好索引另一面

前面简要描述了索引的不足之处，接下来我们进行更加详细的展开说明，具体细节如下：

索引各种开销

1

访问集中导致热块的竞争

由于一般来说，最新的值都是最新产生的，所以访问它容易产生热块竞争。举例来说，如： select * from t where id=100000，select * from t where id=99999;select * from t where id=99998;select * from t where id=99997;这些数据很可能是相邻的，那么它们就会在同一个索引块上，这样很容易产生热点索引块竞争。

2

回表性能取决于聚合因子

结论：索引查询要尽可能避免回表，如果不可避免，则需要关注聚合因子是否过大。（注：这个例子在前面的章节已经说过了，这里就不再详述了。）在该例子中，构造脚本organized表的聚合因子比较小，回表的代价较低，产生了2900个buffer，如下：

而disorganized表的聚合因子比较大，回表的代价很高，如下，产生21360个buffer：

3

索引更新方面的开销比较大

环境搭建：

脚本1：无索引，表记录增加，插入不怎么变慢

由上面代码可以看出，虽然t_small是小表，t_big是大表。但是插入一般不会随着记录的增加越插越慢。什么时候会越插越慢，就是当表有索引的时候。因为索引需要维护，越大维护越困难。我们继续做一组试验。

环境准备（建3张结构和记录都一样的表，只是索引分别是6个、2个及无索引）：

分别往这三张表里插记录：

脚本2：有索引的表，记录越多，插入越慢

表记录越大，索引越多，插入越慢，从试验结果来看，这一点还是非常明显的。

4

建索引的过程开销也很大

（1）建索引过程会产生全表锁

可以通过如下方式查看被锁的情况：

脚本3：建索引产生锁

（2）建索引过程会产生全表排序

未建索引前，观察一下数字字典中记录的系统排序情况，如下：

建索引后，继续观察，发现排序次数sorts (memory)增加了，如下：

脚本4：建索引产生排序

索引各种开销的总结：

索引使用失效

请到「今天看啥」查看全文