mysql - 触发器性能下降(使用或不使用)

Question

我已经创建了这个触发器:

DELIMITER $$
CREATE TRIGGER `increment_daily_called_count` BEFORE UPDATE ON `list` 
FOR EACH ROW begin
  if (NEW.called_count != OLD.called_count) then
    set NEW.daily_called_count = OLD.daily_called_count(NEW.called_count-OLD.called_count);
    set NEW.modify_date = OLD.modify_date;    
  end if;
end
$$
DELIMITER ;

这个运行的数据库表被更大系统中的 100 个不同脚本访问和使用，触发器的原因是我不必在这些脚本中寻找 called_count 可能更新的每个小地方...

我担心的是，因为这个特定的表不断被修改(我每秒说几十次)，这是否会给数据库带来过度的压力？从长远来看，在无数脚本中查找所有 called_count 更新查询并添加 daily_called_count = daily_called_count+1 是否更好？

一些细节我想知道这里的答案:

• 使用此触发器是否实质上使这 3 个单独的更新查询在它曾经是单个查询的地方，或者 MySQL 是否足够智能以捆绑这些查询？
• 对于使用触发器搜索和修改原始查询是否有性能论据？
• 此触发器是否会导致我没有预料到的任何不可预见的怪异现象？

Answer 1

两个免责声明:

1. 我已经很长时间没有使用 MySQL 了，也从未使用过触发器。我只能根据 RDBMS 的一般经验来谈。
2. 真正了解任何事情的唯一方法是运行性能测试。

也就是说，我尝试用半受过教育的猜测(根据经验)来回答:

Does use of this trigger essentially make this 3 separate update queries where it was once a single query, or is mysql smart enough to bundle these queries?

我不认为这是语句执行意义上的单独更新。但是您正在为每一行添加计算开销成本。

不过，我更担心的是这个触发器的逐行特性。它的字面意思是 FOR EACH ROW。一般而言，与基于 SET 的操作相比，RDBMS 中的逐行操作的扩展性较差。 MS SQL Server 运行语句级触发器，其中传入整组受影响的行，因此无需逐行操作。这可能不是 MySQL 触发器中的一个选项 - 我真的不知道。

Is there a performance argument for hunting down and modifying the originating queries over using the trigger?

这肯定会让系统做更少的工作。从数字上看，性能影响有多大，我不能说。你必须测试。如果只有 1% 的差异，则触发器可能没问题。如果它是 50%，那么，寻找所有代码是值得的。由于寻找代码是一种负担，我怀疑它要么嵌入到应用程序中，要么动态地来自 ORM。如果是这样的话，只要触发器的性能成本可以接受，我宁愿坚持使用触发器，因为它在数据库中保留了特定于数据库的详细信息。

测量，测量，测量。

Could this trigger cause any unforeseen weirdness that I'm not anticipating?

想到缓存。如果这些列是应用程序读取和缓存的内容的一部分，那么它的缓存失效可能与它认为它更改了数据的时间有关。如果数据库更改其下的数据(例如使用触发器)，缓存可能会导致处理过时数据。