学步园

此次DDL为 add column，即会触发表拷贝数据到新表，完成再重命名后再将老表删除。而删除老表的过程会引发scan BP中的老表的page，做清理操作。在BP比较大的情况下，这个操作（buf_LRU_invalidate_tablespace）比较慢，近1s。另外，5.1有个bug,导致多次扫瞄。

执行期间观察db的情况,发现慢日志里确实连最基本的根据主键ID查询的sql 也堵住了，查询都在等待Opening tables

DDL操作在删除老表的过程也是占用LOCK_open这把全局锁，如果占用1s，这期间，所有应用会被阻塞于”Opening tables” 或”Closing tables” ， 就是在等待LOCK_open，hang住整个系统，而这个hang的时间与bp大小有关，确切说是和bp LRU list长度有关

• drop table操作过程

（1）不允许后续的insert buffer merge操作，等待现有merge操作完成

（2）不允许tablespace上后续的IO与flush操作，等待现有操作完成

（3）由于adaptive hash（adaptive hash index是记录级别的hash index,存储记录项到索引页面的映射）存在，需要drop table在adaptive hash所有的记录，从LRU尾部开始遍历，对于每个属于drop
table的page,判断page中是否有记录进入adaptive hash，并收集，收集到1024个这样的page后，释放bp mutex,释放page在adaptive hash中的记录，然后重新获取bp mutex，继续遍历直到头部

（4）再次遍历bp LRU list，释放所有drop table 对应的page,获取bp mutex，遍历bp LRU list，若为dirty page，将dirty page设置为clean page，从flush list中移除，再将page从LRU list中evict ，并添加到free list,最后释放bp mutex

通过上述操作可以看出，drop table 需要遍历bp LRU list两遍，释放adaptive hash操作中记录会定期释放bp mutex对系统hang影响较小，因此释放page操作才是元凶

而由于连接地做DDL，导致应用有累积，即如果1s有100个TPS过来，而DB只能处理10个，有90个未处理，累积60s，导致并发线程量非常大，DB性能也就会指数下降（>512时性能基本不能看）

• 处理策略

1. DDL要防止累积效应，命令间隔地sleep。

2. 多实例BP更小，scan更快，锁住一个bp不会导致整个系统hang

3. innodb_lazy_drop_table=on（percona 5.5）会有所帮助