我有一个用于统计的数据库，有 2000 多个表，每个表有大约 1 亿行。
我认为每周检查几次表以确保它们健康，如果不是，则修复和优化它们会很好。
60% 的表格每天更新，其余为存档。
我的问题是关于check(repair)/optimize：每周检查几次表的健康状况并对其进行优化以确保系统顺利运行是否很好？
【问题讨论】：
标签： mysql optimization
通常，当磁盘上的数据文件碎片过多时，您需要优化表（使用文件系统工具检查 - GiantRobot 链接的脚本不计算碎片），当有许多行更新并更改其大小时（即会创建行碎片）或删除许多记录后，您不会很快再次添加它们。因为 MySQL 将空闲空间用于新行，所以当删除记录和新记录具有相同的行大小时，不需要 OPTIMIZE。
CHECK TABLE 仅在您怀疑数据损坏（在正常运行期间不应发生）时使用。一些 linux 发行版（例如 Debian）有启动脚本，在 MySQL 服务器启动时为所有表运行 CHECK TABLE。然后使用 REPAIR TABLE 修复损坏的表。
ANALYZE TABLE 可用于更新索引基数，用于确定查询执行计划。通常只有在特殊情况下才需要。
从您的问题中不清楚您的统计表是如何使用的...有多少写入、删除和读取？我的统计表一直在写入，每天读取一次，合并数据并写入其他表，然后删除。在这种情况下，不需要运行 OPTIMIZE，因为数据不会经常读取，并且空闲空间会重新用于新数据。我每天都在使用分区，所以我没有删除记录（这很慢），而是 DROP PARTITION（最多需要 1 秒）
【讨论】：
2000 个表和 1 亿行每个看起来都很大！ 如果您尝试每周优化每个表几次，在优化期间， 表格将被锁定，因此在完成工作之前您将无法编写这些表格 这是一个仅检查碎片表（可能是您的 %60 表）并仅优化碎片表的脚本，如果它有效，请告诉我们。
注意：我无法测试脚本，因为我当前的项目使用的是 windows 机器。 阅读我提供的链接的脚本下方的 cmets 和注释
【讨论】：
大表修复非常慢；您可能应该避免使用 MyISAM 使用非常大的表，尤其是具有大量索引的表。更喜欢对它们进行分区以减少修复时间。这可能需要对您的应用程序代码进行重大更改。
你也可以看到修复问题here
【讨论】：