Trigger Performance Degredation (To use or not to use)
<p>I've created this trigger:</p>

<pre><code>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 ;
</code></pre>

<p>The database table this runs on is accessed and used by 100's of different scripts in the larger system and the reason for the trigger is so I don't have to hunt down every little place in these scripts where the called_count might get updated...</p>

<p>My concern is that, because this particular table gets modified constantly (I'm talking dozens of times per second), is this going to put undue strain on the database? Am I better off in the long run hunting down all the called_count update queries in the myriad scripts and adding daily_called_count = daily_called_count+1?</p>

<p>Some specifics I'd like to know the answer to here:</p>

<ul>
<li>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?</li>
<li>Is there a performance argument for hunting down and modifying the originating queries over using the trigger?</li>
<li>Could this trigger cause any unforeseen weirdness that I'm not anticipating?</li>
</ul>