MySQL未提交事务导致InnoDB表空间不断膨胀的问题复盘

知识点掌握了，还需要不断练习才能熟练运用。下面golang学习网给大家带来一个数据库开发实战，手把手教大家学习《MySQL未提交事务导致InnoDB表空间不断膨胀的问题复盘》，在实现功能的过程中也带大家重新温习相关知识点，温故而知新，回头看看说不定又有不一样的感悟！

问题现象:

早上收到zabbix的信息磁盘空间超过90%，登录到监控系统发现从1天前开始磁盘空间使用率急剧增长，直到触发zabbix的预警。
在排查过程中发现master上的一张表(后续统一简称A表)的物理表空间超过了200多G，然而在slave上A表的物理表空间只有13G。

问题排查：

1.首先检查是不是最近两天有大量数据写入，检查binlog后发现和平时的增长量一致，并无异常。
2.再检查此表是否存在大量的表碎片，检查结果发现没有。但是master和slave上的数据量有差异。
show table status的结果显示master上A表大概有8亿多行数据，而slave上只有3kw。
3.运行select count(*)检查A表的真实数据量，master和slave都是3kw行。说明master的table status结果不准确。
4.检查slave上是否存在有replicate的filter，检查结果无。
那为什么master和slave的数据量差异这么大，还无碎片？
5.怀疑是大量并发的delete导致，于是运行pt-osc整理表空间。
6.运行pt-osc时无法Creating triggers，到数据库中检查processlist发现一运行pt-osc就会产生MDL（metadata lock）锁。
7.检查information_schema.innodb_trx发现有一个事务已经运行了2天。
至此真相大白，找到相关的thread_id并kill，问题解决。
在排查过程中还运行show processlist检查过正在运行的线程，看不到A表上有任何操作，这也是本次问题排查的难点。

问题原因：

由于事务没有完成，A表上的锁不会释放，获取不到metadata的独占锁，因此运行create trigger时出现Waiting for table metadata lock。

注：因为是生产环境所以无法截图

以上就是《MySQL未提交事务导致InnoDB表空间不断膨胀的问题复盘》的详细内容，更多关于mysql的资料请关注golang学习网公众号！