为了简单起见，触发器是实现任何类型的数据库更改跟踪的一种方式。但是，您需要知道使用触发器时幕后发生的事情。
根据MySQL存储过程编程，在第256页的“触发器开销”标题下显示以下内容：
重要的是要记住，触发器必须在其所应用的DML语句上增加开销。实际的开销量将取决于触发器的性质，但是---由于所有MySQL触发器都执行FOR EACH ROW ---对于处理大量行的语句，开销会迅速累积。因此，您应该避免在触发器中放置任何昂贵的SQL语句或过程代码。
触发开销的扩展说明在第529-531页中给出。该部分的重点指出以下内容：
这里的教训是：由于触发器代码将对受DML语句影响的每一行执行一次，因此触发器很容易成为DML性能的最重要因素。触发器主体中的代码必须尽可能轻巧，尤其是-触发器中的任何SQL语句都应尽可能地由索引支持。
在使用触发器时，本书中未提及的另一个因素是：在进行审计日志记录时，请注意将数据记录到什么内容中。我之所以这样说是因为，如果您选择登录到MyISAM表，则在INSERT期间，对MyISAM表的每个INSERT都会产生完整的表锁定。在高流量，高交易量的环境中，这可能成为严重的瓶颈。另外，如果触发器是针对InnoDB表的，并且您从触发器内部记录MyISAM中的更改，则这将秘密禁用ACID遵从性（即，将块事务减少为自动提交行为），无法回滚。
在InnoDB表上使用触发器并记录更改时
- 您登录的表也是InnoDB
- 您已关闭自动提交功能
- 您彻底设置了START TRANSACTION ... COMMIT / ROLLBACK块
这样，审核日志可以像主表一样从COMMIT / ROLLBACK中受益。
关于使用存储过程，您将不得不在DML的每个点上都针对被跟踪的表辛苦地调用存储过程。面对成千上万的应用程序代码，人们很容易错过日志记录更改。将此类代码放在触发器中可以消除查找所有那些DML语句的麻烦。
警告
根据触发器的复杂程度，它仍然可能是瓶颈。如果要减少审核日志记录的瓶颈，可以采取一些措施。但是，这将需要对基础架构进行一些更改。
使用商用硬件，再创建两个数据库服务器
由于审核日志记录，这将减少服务器在主数据库（MD）上的写入I / O。这是您可以完成的方法：
步骤01）在主数据库中打开二进制日志记录。
步骤02）使用便宜的服务器，设置启用了二进制日志的MySQL（与MD相同的版本）。这将是DM。设置从MD到DM的复制。
步骤03）使用第二台廉价服务器，在禁用二进制日志记录的情况下设置MySQL（与MD相同版本）。设置每个审核表以使用--replicate-do-table。这将是AU。设置从DM到AU的复制。
步骤04）mysqld从MD转储表结构并将其加载到DM和AU中。
步骤05）转换MD中的所有审核表以使用BLACKHOLE存储引擎
步骤06）转换DM和AU中的所有表以使用BLACKHOLE存储引擎
步骤07）转换AU中的所有审核表以使用MyISAM存储引擎
完成后
这样做是将审核信息存储在单独的数据库服务器上，还可以减少MD通常具有的写入I / O降低。