1、用这个drop 语句举例： drop table T;在之前的老版本中，但如果表T比较大，占用的各种缓存较多，这个SQL在对表进行删除的时候，需要依次清理掉buffer pool中的page，时间久回比较久；清理的动作会影响到在线的业务;在老版本的内核中的大致逻辑如下：扫描lru链表，如果page属于Ｔ表，就从lru链表，hash表， flush list中删除，回收buffer pool中的block 并标记到free list中，期间会长时间持有buffer pool mutex；清理完成之后free/LRU/flush list Mutex;这种模式称为直接drop模式；而MySQL 5.5.23以后就采用了lazy drop table的模式（包括社区版的5.6、5.7、 8.0版本以及当前所有polardb-mysql版本）：lazy方式: 在移除flush list时，会有一个条件判断，如果已经处理了超过一定数量的page（默认是1024个page），会强制释放当前持有的buffer pool mutex和flush list mutex，并且让出CPU，过一会儿再重新拿回锁继续清理flush list；对于LRU list，则不做处理，因为当这个表被删除后，这些数据页最终会在LRU算法调度下被回收。----------------------------------------------------------------
2、对于truncate table操作：在社区版8.0之前的版本中，还是沿用直接drop模式的模式：遍历lru链表，hash表， flush list，并从这些链表中清理page，回收buffer pool中的block 并标记到free list中，期间会长时间持有buffer pool mutex；清理完成之后free/LRU/flush list Mutex;在社区版5.6、5.7的mysql版本中，truncate 无法采用类似lazy drop table的核心原因如下：是因为truncate table 需要复用 space id, 这导致必须把buffer pool中的老的表中的页全部删除，而drop table因为新旧表的页可用通过space id区分，只需要把flush list中的脏页删除就可以了；在8.0版本之后，truncate就替换为了用drop+create的方式，这样解决了truncate 可能会导致大buffer pool夯的问题。注意：在polardb-mysql中，是在5.7.1.0.2版本中，修复了此问题，采用了drop + create的方式来替换原来的truncate逻辑。3、相关版本说明：（1）、社区版mysql相关的bug fix说明：https://bugs.mysql.com/bug.php?id=68184（2）、社区版MySQL8.0针对该问题说明：On a system with a large InnoDB buffer pool and innodb_adaptive_hash_index enabled, TRUNCATE TABLE operations could cause a temporary drop in system performance due to an LRU scan that occurred when removing an InnoDB table's adaptive hash index entries. To address this problem, TRUNCATE TABLE now invokes the same code as DROP TABLE and CREATE TABLE. The problem was addressed for DROP TABLE in MySQL 5.5.23.翻译：当InnoDB buffer pool比较大和innodb_adaptive_hash_index启用时，TRUNCATE TABLE操作可能由于发生了LRU扫描，删除InnoDB表的自适应散列索引项时，导致系统性能暂时下降。为了解决这个问题，TRUNCATE TABLE现在调用与DROP TABLE相同的代码删除表。因为在MySQL 5.5.23后，DROP TABLE解决了这个问题