标签：flush 删除 buffer drop list mutex MySQL table pool

在一个高负载的生产数据库上删除大表需要一些技巧，倘若直接drop table，将产生大量磁盘I/O，严重的会卡库，这是高可用服务所不能接受的。要优化删除表，需要了解其内部执行过程。

一、表删除过程
表删除原理上分为内存和磁盘两部分操作：

清除表相关的buffer pool页面。
删除表相关的磁盘文件。
1. buffer pool清除
删除表时，MySQL会将表在buffer pool中对应的页面清除，这个过程中会对buffer pool上一个全局排它锁。在MySQL 5.5.23以后的版本，实现了一个lazy drop table方式，以减轻清理内存结构的操作对系统吞吐量产生的波动，具体的过程：

1. 持有buffer pool mutex；
2. 持有buffer pool中的flush list mutex；
3. 开始扫描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. 重新持有flush list mutext；
4. 释放flush list mutex；
5. 释放buffer pool mutex；

上面的过程中持有了buffer pool mutex和flush list mutex，从锁的保护范围来看，buffer pool mutex直观上瓶颈会比较明显。如果buffer pool很大，或者表有很多脏页面需要被清除，则持有mutex的时间会相对较长，导致其它事务在用到相应buffer pool实例时被阻塞，从而影响整个数据库性能。

这部分的优化的难点在于涉及源码，作为应用能做是先要保证被删除表上没有活动事务，最好是没有任何访问，然后在业务低峰期执行表删除操作。

2. 删除表相关的磁盘文件
这里只讨论采用独立表空间（innodb_file_per_table=1 ）的innodb表删除。独立表空间在性能和运维上都大大强于共享表空间，也是当前绝大多数情况下的表存储方式。相对于内存扫描，删除磁盘文件对系统的影响要大得多。问题在于如果表文件过大，直接删除会瞬时占用大量I/O，造成IO阻塞。通常可以使用以下三个步骤删除大表：

创建表文件的硬链接。
drop table删除表。
删除表文件释放磁盘空间。
http://mysql.taobao.org/monthly/2016/01/07/

标签：flush,删除,buffer,drop,list,mutex,MySQL,table,pool
来源： https://www.cnblogs.com/lovezhr/p/15155834.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。