为什么我的mysql表必须频繁优化

我有一个mysql表，有12列，一个主键和两个唯一键。我在这个表中有大约86000行/记录。 我使用以下mysql代码：

INSERT INTO table (col2,col3,-------col12) VALUES ($val2,$val3,----------$val12) ON DUPLICATE KEY UPDATE col2=VALUES($val2), col3=VALUES($val3),----------------col12=VALUES($val12)

当我从cpanel phpmyadmin查看此表的结构时，我可以在表的索引信息下方看到“optimizetable”链接。如果我单击该链接，表将被优化

但我的问题是，为什么我经常在这个表中看到“优化表”链接（出现在3/4天内），而这个数据库的其他表却不显示“优化表”链接（它们每个月显示一次链接，甚至每两个月或更长时间显示一次链接）

---

由于我没有删除此表行，只是插入，如果发现重复键，只是更新，那么为什么需要如此频繁地进行优化？

简短回答：切换到Innodb

MyISAM存储引擎使用BTree作为索引并创建索引文件。每次插入大量数据时，这些索引都会发生更改，因此需要优化表以重新组织索引并重新获得一些空间

MyISAM的索引机制比Innodb占用更多的空间

阅读下面的链接

---

Innodb与MyISAM相比还有许多其他优势，但这是另一个主题。

我将解释插入记录如何影响MyISAM表，并解释优化的作用，这样您就可以理解为什么插入记录会产生如此大的影响

数据

使用MyISAM，当您插入记录时，数据只需附加到数据文件的末尾

在MyISAM表上运行optimize会对数据进行碎片整理，对数据进行物理重新排序以匹配主键索引的顺序。这加快了顺序记录读取（和表扫描）的速度

索引

插入记录还会将叶子添加到索引中的B树节点。如果节点已满，则必须将其拆分，实际上至少重建该索引页

在优化MyISAM表时，索引会被展平，以便在重建索引页之前有更多的扩展（插入）空间。这个更平坦的索引也加快了搜索速度

统计数据

MySQL还存储关于密钥分布的每个索引的统计信息，查询优化器使用这些信息来帮助制定良好的执行计划。插入（或删除）许多记录会导致这些统计信息过时

优化MySQL会在对索引进行碎片整理和重建后重新计算表的统计信息

与追加

在追加数据时（添加主键值较高的记录，如使用auto_increment），该数据不需要在以后进行碎片整理，因为它已经处于正确的物理顺序。此外，在索引中追加（按顺序插入）节点时，节点保持平坦，因此也不需要在那里进行重建

与InnoDB的对比

InnoDB在插入时也会遇到同样的问题，但由于数据是由主键根据其聚集索引保持有序的，因此您可以提前（在插入时）将数据保持有序，而不必在以后对其进行碎片整理。尽管如此，优化InnoDB确实通过展平B树节点和释放未使用（已删除）的键来优化数据，这改进了顺序读取（表扫描），并且二级索引与MyISAM中的索引类似，因此需要重新构建以展平它们

结论

我并不是想证明我和MyISAM在一起。InnoDB由于聚集索引而具有优异的读取性能，由于记录级锁定而具有比MyISAM的表锁定更好的更新和追加性能（假设并发用户）。此外，InnoDB还具有酸性

不过，我的目标是回答你的直接问题，并提供一些技术细节，而不是猜测和道听途说

---

这两个数据库存储引擎都不会自动优化自身。

是否启用了innodb_file_per_table？是否在唯一键中更新列？不，它不是innodb结构化表，它的引擎是MyISAMNo，查询中不会更新唯一键列。innodb也使用B树作为索引。InnoDB的聚集索引可能会降低插入性能。是的，它使用B树，但存储方式不同。不，这在一天之内是真的，现在不是了。如果您正确配置innodb，它在任何情况下都会比MyISAM性能好。更不用说MVCC可以防止锁定并使备份更容易。我想不出这一点，但如果您使用的MySQL版本早于5.6，MyISAM是唯一具有全文搜索功能的存储引擎。但是innodb现在支持全文搜索。答案的第二部分是phpmyadmin只是基于任意公式进行猜测。仅仅因为一个工具表明某个操作是适当的，并不意味着你应该相信它，特别是任何据称有想法可以帮助你优化或“调优”你的服务器的工具。有时，自动化的建议只是浪费时间；其他情况下，这可能会对性能造成不利影响。不幸的是，MyISAM也是唯一一个支持空间（R-Tree）索引的引擎，但是如果您还没有使用它们，那么您可能没有针对它们的应用程序+1 InnoDB ftw。