怎样解决ibdata1共享表空间文件一直增加的问题

这期内容当中小编将会给大家带来有关ibdata1共享表空间文件一直增加的，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。数据库磁盘使用率一直上升，其中ibdata1使用有323G，并且一直增加持续了31天1、首先看了实例innodb_file_per_table是开启的2、5.6版本undo信息那么ibdata1文件增大的原因有如下因素：InnoDB 引擎表由于支持多版本并发控制（MVCC），因此会将查询所需的Undo信息保存在系统文件ibdata1中。如果存在对一个InnoDB表长时间不结束的查询，而且在查询过程中表有大量的数据变化，则会免费主机域名生成大量的Undo信息，导致 ibdata1文件尺寸增加。由于 MySQL内部机制的限制，ibdata1文件目前是不支持收缩的。因此出现这样的情况，只能通过切换主备，或者迁移，再或者增大存储空间解决。建议：监控和清理执行时间过长的会话或事务。
那么今天的例子大致如下：通过show processlist 看到一个sql执行了31天，并且还处于query，Sending data状态，SQL本身三个表关联，没有关联条件，后面kill掉此sql，通过切换实例，新备重新搭建对于数据文件占用空间高的情况，可以通过清理数据的方式来减少空间占用情况，比如通过drop table和truncate table来清理不再需要的数据。说明 3 个常见问题：information_schema.tables 提供的是根据采样获取的表的部分统计信息，因此通过下面的查询获取的表、库数据尺寸和实际数据文件占用尺寸间会有出入（通常要小于实际数据文件占用空间）下图中可以看到：在收集表的统计信息前后反馈出的表数据量大小存在差异。
注：即使通过 analyze table 命令，重新收集统计信息，得到的数值通常也小于实际数据文件占用空间；比如本例的16143 MB 也小于该表的数据文件实际占用空间。由于数据文件在频繁的 DML 后会出现数据空洞的现象，比较接近实际数据文件占用空间的计算方法请参考：注：
因为 information_schema.tables 中提供的是采样统计数据，因此该计算方式在统计数据比较接近实际的情况下，才会比较接近真实空间占用情况。delete 操作不能够直接回收被删除数据占用的数据文件空间，这就好比排空泳池中水但泳池的占地面积不会发生改变一样。而且 delete 操作会生成相应的 Binlog 文件，会进一步恶化空间使用情况。在 delete 操作删除数据后，需免费主机域名要通过 optimize table tab_name; 操作来回收空间。自建MySQL可能存在备份占用空间的问题，但是云上RDS 备份放置在后台 OSS 上，不占用用户的 RDS 实例空间，因此删除备份不能解决实例的空间问题。而且删除备份会影响实例的可恢复性，强烈建议任何情况下不要考虑删除备份。临时文件会随查询的结束或者会话的终止而自动释放，因此如果是临时文件导致实例空间满而锁定，可以通过终止会话来释放空间。遇见过一个案例，客户排序操作导致ibtmp1很大，占用空间很高，需要释放，那么只能重启，也是切换成备库，然后重启新的备释放掉了ib_logfile 日志文件：ib_logfile0 和 ib_logfile1 日志文件保存 InnoDB 引擎表的事务日志信息，其文件大小尺寸固定，不可以改变。较大的尺寸在高并发事务的场景下有利于减少事务日志文件切换的次数，提高实例性能。上述就是小编为大家分享的ibdata1共享表空间文件一直增加的了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注云技术行业资讯频道。

相关推荐: RR模式下insert..selcet sending data状态是怎样的

RR模式下insert..selcet sending data状态是怎样的，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。例如：其中的sending data是什么意思。隔离级别为RR，语句为…