为何建议频繁重建数据庞大且性能至关重要的表？

本文共计3745个文字，预计阅读时间需要15分钟。

个人创作公约：本人声明的所有文章均为原创，如若引用任何文章，将明确标注出处。如有疏漏，欢迎批评指正。如若发现网上有抄袭本人文章的情况，欢迎举报，并将给予奖励。

个人创作公约：本人声明创作的所有文章皆为自己原创，如果有参考任何文章的地方，会标注出来，如果有疏漏，欢迎大家批判。如果大家发现网上有抄袭本文章的，欢迎举报，并且积极向这个 github 仓库 提交 issue，谢谢支持~

本文是“为什么我建议”系列第三篇，本系列中会针对一些在高并发场景下，我对于组内后台开发的一些开发建议以及开发规范的要求进行说明和分析解读，相信能让各位在面对高并发业务的时候避开一些坑。
往期回顾：

• 为什么我建议在复杂但是性能关键的表上所有查询都加上 force index
• 为什么我建议线上高并发量的日志输出的时候不能带有代码位置

一般现在对于业务要查询的数据量以及要保持的并发量高于一定配置的单实例 MySQL 的极限的情况，都会采取分库分表的方案解决。当然，现在也有很多 new SQL 的分布式数据库的解决方案，如果你用的是 MySQL，那么你可以考虑 TiDB（实现了 MySQL 协议，兼容 MySQL 客户端以及 SQL 语句）。