mysql - MySQL 事件调度的性能影响

Question

我有一个在 MySQL 数据库上创建临时用户，然后在 24 小时后删除它们的用例。我会做足够多的工作，以至于我想自动化该过程并将其与用户创建脚本打包在一起，这样我就不必跟踪该过程。

我在互联网上四处寻找有关 MySQL 事件调度的性能影响的文档、问题和八卦，但我没有发现任何令人沮丧的事情。我看到了另一个关于“成本”MySQL 计划事件的问题，但讨论主要涵盖了使用 cron 与使用 MySQL 事件计划来计划数据库任务之间的比较。

我在 Amazon RDS 上运行，所以 cron 对我不起作用。 MySQL 事件调度看起来是正确的解决方案。我正在安排一个非常轻量级的事件——在创建 24 小时后一次删除一个用户——但我必须保持 MySQL 的事件调度程序 24/7 启用。这有任何性能成本吗？如果没有，为什么默认情况下不启用事件调度程序？

Answer 1

与调度程序运行的 SQL 的成本相比，调度程序的成本无关紧要。本书High Performance MySQL讨论这个:

Events are initiated by a separate event scheduler thread, because they have nothing to do with connections. They accept no inputs and return no values -- there's no connection for them to get inputs from or return values to....Similar considerations to those that apply to stored procedures apply to events. First, you are giving the server additional work to do. The event overhead itself is minimal, but the SQL it calls can have a potentially serious impact on performance.

In current versions of MySQL, the event scheduler is enabled by default.

我怀疑，在早期版本中，有人担心默认启用事件会产生意外的 impact on statement-based replication ，高性能 MySQL 还讨论了:

[E]vents can cause the same types of problems with statement-based replication that other stored code can cause.

最终，就像任何数据库问题一样，您必须在您的模式中实现解决方案并衡量效果，因为没有两个实例是相同的，也没有解决方案是通用的。