php - 在每次页面加载时自动索引、修复和优化 MySQL 表

Question

我正在和一个人辩论，他告诉我使用他的函数不会影响性能......

在运行页面的每个用户加载的每个页面上使用 PHP 类 __destruct() 自动索引、修复和优化 MySQL 表。

他问我为什么我认为这对性能不利，但我真的不知道，有人可以告诉我为什么这样的事情不好吗？

更新他的推理......

优化和修复数据库表消除了开销的字节大小，当涉及多个连接和表使用时，这些字节大小实际上会减慢额外的查询。即使使用启用了索引的性能增强的数据库架构。

更不用说执行这些操作的执行时间在内存和处理器线程中几乎没有。

打开、读取、写入、更新然后自己清理对我来说更有意义，然后执行相同的操作并留下不必要的开销等待 cron 条目清理。

Answer 1

与其争论，不如衡量？使用工具包来分析您花时间的地方，例如 Instrumentation for PHP .证明您的 PHP 请求的优化步骤花费了很长时间。

重建索引是一个昂贵的过程，至少与在没有索引的情况下进行表扫描一样昂贵。你应该不经常建立索引，这样你每次建立索引时，你都会在索引的帮助下处理许多 PHP 请求。如果您在每个 PHP 请求上构建索引，您最好根本不定义索引，而只是一直运行表扫描。

REPAIR TABLE 仅与 MyISAM 表(和存档表)相关。我不推荐使用 MyISAM 表。您应该只使用 InnoDB 表。不仅是为了性能，也是为了数据安全。 MyISAM 非常容易受到数据损坏的影响，而 InnoDB 在大多数情况下通过维护每页的内部校验和来防止这种情况。

InnoDB 表的 OPTIMIZE TABLE 重建所有数据和索引页。一旦你的 table 增长到一个非常大的尺寸，这将是非常昂贵的。当然不是你想在每次页面加载时都做的事情。我什至会说你不应该在 任何 PHP 网络请求期间执行 OPTIMIZE TABLE -- 通过一些脚本或管理界面离线执行。

表重组也会锁定表。您会将访问同一个表的所有其他 PHP 请求排队很长时间(即几分钟甚至几小时，具体取决于表的大小)。当每个 PHP 请求都有机会时，它将运行另一个表重组。在每个 PHP 请求上产生如此多的开销是荒谬的。

---

您还可以打个比方:您不会在每次 PHP 请求期间重建或优化整个表或索引，原因与您不会在每次启动汽车时都进行调整和换油一样:
这样做既昂贵又不方便，而且与按适当的时间表进行发动机维护相比，它不会带来额外的好处。