问mysql优化表的适当使用

EN

Baron，这篇文章的作者，是高性能MySQL，第3版的合著者之一，这是关于MySQL性能的最好的书之一。虽然权威的论点并不总是好的，但我想说的是，他可能知道他在说什么。

尽管他所说的一切都是正确的-in --我的基本观点--但您必须理解实际的基本论点:在许多情况下，整理InnoDB表是无用的(对于性能而言)，而且许多人经常推荐这样做是错误的。

分割和分页是一个微妙的话题，杰里米·科尔( Jeremy http://blog.jcole.us/2013/04/09/innodb-bugs-found-during-research-on-innodb-data-storage/ )和Facebook的工程师们已经提到了很多(特别是关于压缩)：https://www.facebook.com/note.php?note_id=10150348315455933及其对性能的影响。

很多时候，您的性能依赖于负载--是否使用自动增量进行插入？您是否多次在表中间插入和删除？如果你的桌子是动态的，你能负担得起额外的磁盘空间吗？

我可以向您推荐一些好的实践(这可能是您想要的)：

• 只有在完成了大量记录的批量删除(并且您不打算将它们插入回)时，才会进行碎片整理。在其他情况下，可能没有必要这样做。如果您想知道逻辑数据和文件大小之间是否存在巨大差异，请将.idb文件与显示表状态中的数据+索引大小进行比较。
• 通过始终按主键顺序插入加速插入，因此不会强制不必要的分页。
• 使用分区隔离可能更改表内部结构的更改。
• 没有办法“优化二级索引”，但我从来没有发现这样的事情是必要的。change缓冲区确保对索引的更改/再平衡是异步完成的，不会出现严重的性能问题。BTREE应该始终保持平衡，因此假设您的更改缓冲区没有满，并且清除线程会迅速删除旧行记录，那么您的性能应该是正常的。我可以认为“优化二级索引”的一种方法是DROPing索引并重新创建它(您正在使用InnoDB插件或MySQL 5.5+)，但我认为绝对没有理由这样做。

当然，如果您真的想深入研究这个主题，请创建一些表，对它们进行碎片整理，并检查之后是否确实有一些收获。通常，表空间处理和统计数据收集在InnoDB上是相对自动的。