我一直在使用一种方法来查看使用查询来测量表格大小，例如：
INSERT INTO tableRecords (loadTime, dataFromDate, tableName, rowCount, sizeMB)
SELECT NOW(),
SUBDATE(CURDATE(),1),
'table_name',
COUNT(*),
(SELECT ROUND(((data_length + index_length) / 1024 / 1024), 2)
FROM information_schema.TABLES
WHERE table_schema = 'db_name' AND table_name = 'table_name')
FROM table_name
我每天都在运行这段时间
但是，我注意到，无论添加多少行，数字都会保持相同的数天
有更好的方法可以确保我获得当前的表格大小吗？
我可以使用我正在使用的脚本运行多个查询
意识到OPTIMIZE TABLE命令，但我不确定它是正确的使用方式，也不确定是否/何时使用它。有必要解决我的问题吗？我可以看到在我的情况下每天运行所有OPTIMIZE TABLE命令需要一些时间（一些大表）
如果这是正确的方法，我应该在INSERT之前每天运行此命令吗？
还有其他选择吗？
答案 0 :(得分：2)
您应该知道在INFORMATIONS_SCHEMA.TABLES中报告的表格大小的数字只是一个估计 - 它可以是+/- 10％或更多。当MySQL更新其统计信息时，它也可能会不时发生变化。
这可能就是为什么即使你插入很多行，这个数字似乎也没有改变。您可以使用ANALYZE TABLE强制统计信息更新。
使用SHOW TABLE STATUS实际上只是在INFORMATION_SCHEMA中读取相同的值，因此它具有相同的精度问题。
查看磁盘上的物理文件大小也不准确，因为该文件通常可以包含一些碎片，来自过去的删除或未完全填满文件中给定空间的行。因此，数据的实际大小与文件的物理大小完全不同。
这也意味着表格的“大小”可能意味着不同的东西。它是真实数据行的大小吗？数据占用的页面大小？页面大小如果进行了碎片整理？磁盘上物理文件的大小？
为什么你需要这样精确的表格尺寸呢？即使您可以获得完全精确的表格大小测量，一旦插入另一行，它就会过时。这就是为什么估计足以满足大多数目的。
至于何时使用OPTIMIZE TABLE，我建议在我完成一些可能导致严重碎片的操作后使用它，比如一系列许多DELETE语句。或定期进行碎片整理。频率取决于桌面上的活动水平。每年流量低的表就足够了。每隔几周就有一个包含大量插入/更新/删除的表。每天这样做可能有点矫枉过正。
你是正确的，它会锁定你的表并阻止活动一段时间，表越大，它需要的时间越长。您可以使用pt-online-schema-change允许您的表格重组在后台进行，而不会阻止原始表格上的活动。
此外，MySQL 5.6可以为InnoDB表做OPTIMIZE TABLE online DDL，而无需锁定。
重新评论：
InnoDB会不时更新统计信息，但在自动刷新统计信息之间并不是几天。以下是一些可以更详细地讨论此内容的参考资料：