BEFORE 触发器和 ON UPDATE CURRENT_TIMESTAMP 之间的性能差异 - MySQL
Posted
技术标签:
【中文标题】BEFORE 触发器和 ON UPDATE CURRENT_TIMESTAMP 之间的性能差异 - MySQL【英文标题】:Performance Difference between BEFORE Trigger And ON UPDATE CURRENT_TIMESTAMP - MySQL 【发布时间】:2018-09-28 10:58:34 【问题描述】:因此,我和我的朋友对使用 BEFORE 触发器或 ON UPDATE CURRENT_TIMESTAMP 来更新表的 updated_at
列的值存在争论。顾名思义,列的用途只是存储行的最后一次更新时间。
他已经为此设置了触发器-
事件 - BEFORE
BEGIN
set NEW.updated_at := current_timestamp();
END
我认为我们应该使用属性 ON UPDATE CURRENT_TIMESTAMP,因为这是 mysql 为相同但在 AFTER
事件上提供的默认触发器。
我尝试在文档中搜索性能差异,但一无所获。 有什么帮助吗?
【问题讨论】:
我个人会将 updated_at 定义为时间戳。 差别很小;寻找其他需要优化的领域。 【参考方案1】:毫无疑问,ON UPDATE CURRENT_TIMESTAMP
方法比触发器更快(尤其是在重负载下),因为它更简单。您当然可以将其视为默认触发器,但它实际上是内置在数据库的 UPDATE 代码中的。 DBMS 中的执行路径不需要任何特殊的逻辑来处理事务,而触发器则需要。
时间戳更新与任何其他更新同时发生;无论是在它之前还是之后。如果更新(事务性)回滚,则时间戳更改将与其余更改的列一起回滚
未来的程序员也更容易理解您的表,因为他们可以只查看列定义,而不必知道触发器。 (但这是一个见仁见智的问题。)
@AS7K 运行了一个基准测试,结果显示在此处。 MySQL timestamp auto-update performance
但是,还有更重要的设计决策需要争论。 (也是意见问题。)
【讨论】:
啊,这说明了事情。难怪在文档中找不到它。现在,我想知道时间令牌的更新何时发生。之前还是之后? 谢谢。到目前为止,这似乎是合乎逻辑的。但是,如果您知道这方面的来源,那将是完美的。以上是关于BEFORE 触发器和 ON UPDATE CURRENT_TIMESTAMP 之间的性能差异 - MySQL的主要内容,如果未能解决你的问题,请参考以下文章