我想知道OPTIMIZE TABLE tbl_name在MySQL Server中运行查询可以带来的[真正实用]好处。

我检查了一次，发现运行此命令后，下一个数据库命中可能花费很长时间，可能是由于碎片的重定位所致，但是随后的命中表现出某种性能，我不确定查询缓存是否能做到这一点与优化或仅优化一起完成此技巧。

如果可能的话，任何人都可以用一些实际的性能差异值来指导我，以便随着MySQL的使用在我们的项目中日益受到重视，我可以继续做下去。

请记住，OPTIMIZE TABLE不会执行碎片整理。在内部，OPTIMIZE TABLE执行多项操作（将数据复制到临时文件，重新创建索引，重新计算索引统计信息）。实际上，我的示例可以手动执行，如图所示。

示例：如果您进行优化mydb.mytable，请输入以下命令：

OPTIMIZE TABLE mydb.mytable;

请注意，mysql在后台执行以下操作：

CREATE TABLE mydb.mytable2 LIKE mydb.mytable;
ALTER TABLE mydb.mytable2 DISABLE KEYS;
INSERT INTO mydb.mytable2 SELECT * FROM mydb.mytable;
ALTER TABLE mydb.mytable2 ENABLE KEYS;
DROP TABLE mydb.mytable;
ALTER TABLE mydb.mytable2 RENAME mydb.mytable;
ANALYZE TABLE mydb.mytable;

这对于经历大量UPDATE和DELETE的表非常有用

执行此操作可以完成两件事

1. 防止mysql浏览表中的片段，以尝试将数据加载到正确大小的片段中。消除这些碎片将减少此操作。

2. 重新计算索引统计信息有助于MySQL Query Optimizer构造更好的EXPLAIN计划。否则，由于MySQL查询优化器决定对EXPLAIN计划做出错误的猜测，因此查询的执行时间可能会变差。这将是具有大量UPDATE和DELETE的表的明确症状。

警告

关于缓存，由于进行了全表扫描，因此缓存很快就花光了。对于MyISAM索引页面流入和流出MyISAM密钥缓存。对于InnoDB，数据和索引页流入和流出InnoDB缓冲池。