阅读完本篇文章需要3分钟
今天讨论一下业务上线一段时间后，MySQL由于表空间碎片导致查询变慢的问题
影响数据库能的因素不只有硬件性能，规范的数据库模型设计和参数设置，以及高超的SQL编写技巧。除此之外还有很多其他因素，比如统计信息没有及时更新，再者还有表空间碎片过多等。
其实MySQL内部会根据表数据变更的阈值自动更新统计信息，当然可以自己设置参数值，但是一般并不会去动它。最好有定时 job 隔段时间去强制更新统计信息。当然统计值是抽样计算的，如果一个数据页一个数据页的去计算，那数据库还工作不工作了。
当然有很多开源的监控工具是可以监控表碎片信息的，比如利用 Grafana 和Prometheus 打造自己的监控系统是个不错的选择。
1更新统计信息
我们常用的更新统计信息的脚本。
analyze table address;
更新完统计信息，你可以show table xxx status，或者查看系统表看值有没有更新。
2优化表空间
而更新表碎片会用 optimize
optimize table address;
输出信息为
但是有人看到输出信息会觉得InnoDB表是不是不支持optimize啊，其实是支持的，不要被这个输出信息所误导。在底层 MySQL会将该 optimize 转化为下面的操作，其实还是会重建表。
alter table address force ;
如果你不想深入了解 MySQL 源码，可以在执行命令时监控一下文件的变化。
比如我接下来安装inotify工具来看一下
此时我们监控数据目录文件的状态，同时去优化表
optimize table address;
可以看到确实是重建了表
那是不是只能用optimize了，当然不是，既然是重建表，那还不如通过更改引擎的方式重建表
alter table address engine innodb;
这时有人会问，涉及到表结构变更，是不是最好不要直接操作，规范做法不是利用pt工具或者gh-ost工具吗？其实如果你使用的是8.0.26或者8.0.29这些高版本的数据库，完全没必要。
MySQL的在线DDL已经很不错，加锁时间很短的，而且变更时间远小于用这类工具操作的时间。
而且MySQL的DDL操作有三种算法，根据操作的不同，采取的算法也不同，有些甚至是不会有任何阻塞的，只需要改一下元数据就可以了。
哪可能又有人问了，要不要升级到这么高的版本？答案是很有必要，其实最近的20以上的版本并没有特别激进的功能，反而修复了不少bug，强烈建议更新。
原文始发于微信公众号（小新数据库）：MySQL表碎片的那些事
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/207618.html
