但对象的删除，如果同步清理对象的缓存的话，不仅大大增加了延时，同时可能因为缓存过大导致IO blooding。所以针对缓存的清理，都会采用lazy drop的优化，下面我们就来对比下percona和官方针对drop table的lazy drop 优化。

假设使用为表创建独立的tablespace，在业务处理过程中，有删除表的动作，会发现drop table操作不仅仅持续比较长，而且在删除过程中，实例的QPS也有所降低，主要是因为在清理buffer pool过程中，持有buffer pool的mutex导致，percona server在5.1版本开始引入 lazy drop table来消除drop table过程中带来的影响，但也并没有完全消除，MySQL 官方在5.5.23以后也引入了 lazy drop table 来优化drop 操作，下面我们就来对比一下这两种方式的差异。

值得一提的是：在日常的运维中，drop的操作并非核心需求，我们也都建议DBA在 off-peak 时间去做这样的操作。

在讨论lazy模式之前，我们先看看MySQL在5.5.23版本之前的处理方式即同步模式: 当要drop table的时候，会在整个操作过程中持有buffer pool的mutex，然后扫描两次LRU链表，把属于这个table的page失效掉，buffer pool中page的个数越多，持有mutex时间就会越长，对在线业务的影响也就越明显。

简短看下核心处理代码:

  1. buf_LRU_drop_page_hash_for_tablespace会扫描一次LRU list，需要从adaptive hash中删除对要删除的表的page的引用；
  2. buf_LRU_invalidate_tablespace_buf_pool_instance会扫描一次LRU list: 如果是dirty block，需要从flush list remove掉，然后从page hash中删除，最后从LRU list中删除。

可以看到，这种同步清理掉内存结构的操作，在业务高峰期，对系统的吞吐能力会产生不小的波动。

其处理drop table的过程如下:

  1. 持有buffer pool的lru list mutex锁；
  2. 开始扫描LRU list中的page；
    1. 如果这个page属于要删除的table的，就设置一个flag，表示这个page所在的表正在被删除
  3. 持有一个adaptive hash index的shared latch；
  4. 开始扫描buffer pool中的block；
  5. 如果这个page被AHI索引；
    1. 释放AHI 锁
    2. 持有page的exclusive lock
    3. 删除AHI中索引这个page的entries
    4. 释放page锁
    5. 持有AHI的shared lock进行下一个page的判断

相比较同步模式，Percona的lazy drop table在扫描lru list过程中，只set了一个flag，随后在lru正常的淘汰过程中或者flush dirty block的时候如果碰到这中block，直接就做删除处理了，这也就是lazy的核心。

其核心代码如下：

在MySQL 5.5.23以后的版本，也实现了一个lazy drop table的方式，和percona的方式有所区别，下面来看一下具体的过程：

  1. 持有；
  2. 开始扫描flush list；
    1. 如果dirty page属于drop table，那么就直接从flush list中remove掉；
    2. 如果删除的page个数超过了#define BUF_LRU_DROP_SEARCH_SIZE 1024 这个数目的话，释放buffer pool mutex，flush list mutex，释放cpu资源；
      • 释放flush list mutex；
      • 释放buffer pool mutex；
      • 强制通过pthread_yield进行一次OS context switch，释放剩余的cpu时间片；
    3. 重新持有buffer pool mutex；
    4. 重新持有；
  3. 释放flush list mutex；

相比较percona的lazy方式，这里扫描的是dirty block，在LRU list中进行淘汰的时候，就不再判断当前fil_space是否存在的问题了，因为不牵涉到写入。

这里边有两个相关的bug，、bug#64284，有兴趣可以参考一下。

从上面的percona和oracle的MySQL版本比较来看，percona是持有了LRU list mutex和AHI lock，而MySQL官方版本是持有了buffer pool mutex和flush list mutex，从锁的保护范围来看，buffer pool mutex直观上瓶颈会比较明显，但具体还要跟表的大小、dirty block的比例来看，如果dirty block比较少的话，官方版本并不扫描LRU list，所以可能持有的时间并不会太久。

Percona的开发人员还针对这两个不同版本进行了Benchmarks， 大家可以看下他们测试出来的结果:

这个图是 MySQL 官方版本测试在系统压力下，进行频繁drop table的系统抖动:

这个图是 Percona 版本测试在系统压力下，进行频繁drop table的系统抖动:

Percona版本