在MySQL日常运维中，随着业务持续写入、更新与删除，表会产生碎片、统计信息失真甚至索引损坏等问题。通过内置的优化、分析、检查与修复指令，可以在不依赖第三方工具的情况下维持数据库健康度。本文围绕这四组核心命令展开，说明其原理、用法与注意事项。
一、OPTIMIZE TABLE：优化表空间
OPTIMIZE TABLE用于对表进行碎片整理和空间回收。对于MyISAM引擎，该命令会重建数据文件与索引文件，合并碎片并释放未使用的空间；对于InnoDB，在早期的MySQL版本中它会被映射为ALTER TABLE ... FORCE，从而重建表，而在较新版本中若开启了innodb_file_per_table，则通过在线DDL完成类似效果。
频繁执行DELETE或UPDATE的表容易产生空洞。例如日志表每天清理旧数据，若长期不优化，磁盘占用虚高且全表扫描变慢。以下示例对orders表执行优化：
-- 优化单表 OPTIMIZE TABLE orders; -- 同时优化多个表 OPTIMIZE TABLE users, logs, orders;
需要注意的是，OPTIMIZE TABLE在执行期间通常会锁表（MyISAM为表级锁，InnoDB在部分版本也会短暂锁表），因此应在低峰期操作。对于巨量数据表，可考虑使用pt-online-schema-change等在线改表工具替代，以避免业务阻塞。
优化前后的空间对比
可通过information_schema中的TABLES视图观察DATA_FREE字段变化。执行优化前DATA_FREE可能达到数百MB，优化后趋近于零。这一过程实质是让数据页重新紧凑排列，从而减少后续查询的IO消耗。
| 阶段 | DATA_FREE (MB) | 查询耗时 (ms) |
|---|---|---|
| 优化前 | 420 | 180 |
| 优化后 | 2 | 95 |
二、ANALYZE TABLE：更新统计信息
ANALYZE TABLE负责重新采集表的索引分布统计信息，并将结果存入数据字典。MySQL查询优化器依赖这些统计信息来决定是使用全表扫描还是索引查找，以及选用哪个索引。当表数据发生大幅变动后，旧统计信息可能导致优化器误判，生成低效执行计划。
在批量导入数据或大规模删除后，建议主动执行分析。命令使用方式如下：
-- 分析指定表 ANALYZE TABLE products; -- 分析并写表统计到持久化存储 ANALYZE TABLE products PERSISTENT FOR ALL;
对于InnoDB，默认会自动开启innodb_stats_auto_recalc，在表变更超过一定比例时后台更新统计，但该机制存在延迟。手动执行ANALYZE可立刻纠正偏差。与OPTIMIZE不同，ANALYZE通常只读取索引页，对线上影响较小，但在大表上仍会消耗IO，需权衡频率。
统计信息对执行计划的影响
假设某表user_id字段区分度很高，但统计信息过期后优化器认为其选择性低，可能放弃索引而走全表扫描。通过EXPLAIN对比分析前后，可看到type由ALL变为ref，rows预估从十万级降到百级，性能差异显著。
三、CHECK TABLE：检查表完整性
CHECK TABLE用于检测表的结构与数据是否存在错误，包括索引损坏、记录链接异常、校验和不符等。它对MyISAM支持最完整，可发现诸如“表关闭不当”引起的逻辑错误；对InnoDB主要做较为基础的结构校验，因为InnoDB自身具备崩溃恢复能力。
常规巡检脚本中可定期运行检查，以及时发现隐患：
-- 快速检查 CHECK TABLE sessions FAST; -- 全面检查并扩展信息 CHECK TABLE sessions EXTENDED;
CHECK TABLE返回的结果集中，Msg_type为status、error、info等，Msg_text描述具体状态。若返回error，说明表已损坏需修复。生产环境中建议配合监控，将error结果告警出来，避免问题积累到查询失败才暴露。
常见错误类型
- Table is marked as crashed：表被标记为崩溃，多见于MyISAM非正常关闭。
- Checksum failed：数据校验和不匹配，可能磁盘位翻转。
- Found wrong key：索引指向异常记录。
四、REPAIR TABLE：修复损坏表
REPAIR TABLE主要针对MyISAM表的损坏恢复，尝试从数据文件和索引文件中重建索引、剔除坏记录。对于InnoDB，官方通常不推荐用该命令，而是借助mysqldump导出或force recovery模式启动来恢复。
当CHECK TABLE报告崩溃后，可在维护窗口执行修复：
-- 普通修复 REPAIR TABLE sessions; -- 使用排序方式快速重建索引 REPAIR TABLE sessions USE_FRM;
USE_FRM选项在索引文件丢失但.frm结构文件存在时有效，它根据结构文件重新生成索引，风险在于可能丢失部分数据。修复前务必对表做物理备份，避免操作失败无法回滚。此外，REPAIR过程锁表严重，大表修复耗时漫长，应评估是否直接通过备份恢复更划算。
MyISAM与InnoDB修复差异
MyISAM因非事务、易崩溃的特性，REPAIR TABLE是标准救灾手段；InnoDB通过redo日志和doublewrite机制保障一致性，极少需要手动修复，若疑似页损坏，应优先用备份还原而非强行修复，以防数据逻辑错乱。
五、组合实践与自动化建议
在实际运维中，可将四组命令编排为周期任务。例如每周低峰期对核心MyISAM表执行CHECK，若报错则REPAIR；对大流量InnoDB表在批量作业后ANALYZE；每月对历史表OPTIMIZE。下面给出一个简单的Shell调度思路：
#!/bin/bash
# 简易巡检脚本
MYSQL_CMD="mysql -uadmin -psecret shop_db"
for t in logs sessions; do
result=$($MYSQL_CMD -e "CHECK TABLE $t" | grep error)
if [ -n "$result" ]; then
$MYSQL_CMD -e "REPAIR TABLE $t"
fi
done
$MYSQL_CMD -e "ANALYZE TABLE products"
需注意，脚本中密码明文存在安全风险，应改为使用配置文件或交互式读取。对于云数据库，多数厂商已提供自动维护窗口，但仍建议保留手动分析能力应对突发慢查询。
综上，MySQL的优化、分析、检查与修复命令构成了一套轻量但关键的运维工具集。理解其底层行为、锁影响与引擎差异，才能在保障业务连续性的同时，维持数据库高效稳定运行。