MySQL 8.0 FAQ: Triggers Yes. A.5.9. Can triggers access tables? A trigger can access both old and new data in its own table. A trigger can also affect other tables, but it is not permitted to modify a table that is already being used (for reading or writing) by the statement that invoked the function or trigger. A.5.10. Can a table have multiple triggers with the same trigger event and action time? A.5.11. Is it possible for a trigger to update tables on a remote server? In MySQL 8.0, it is possible to define multiple triggers for a given table that have the same trigger event and action time. For example, you can have two  BEFORE UPDATE  triggers for a table. By default, triggers that have the same trigger event and action time activate in the order they were created. To affect trigger order, specify a clause after  FOR EACH ROW  that indicates  FOLLOWS  or PRECEDES  and the name of an existing trigger that also has the same trigger event and action time. With  FOLLOWS , the new trigger activates after the existing trigger. With  PRECEDES , the new trigger activates before the existing trigger. Yes. A table on a remote server could be updated using the  FEDERATED  storage engine. (See Section 16.8, “The FEDERATED Storage Engine” ). Yes. However, the way in which they work depends whether you are using MySQL’s “classic” statement-based or row-based replication format. When using statement-based replication, triggers on the replica are executed by statements that are executed on the source (and replicated to the replica). When using row-based replication, triggers are not executed on the replica due to statements that were run on the source and then replicated to the replica. Instead, when using row-based replication, the changes caused by executing the trigger on the source are applied on the replica. For more information, see Section 17.5.1.36, “Replication and Triggers” . A.5.12. Do triggers work with replication? A.5.13. How are actions carried out through triggers on a source replicated to a replica? Again, this depends on whether you are using statement-based or row-based replication. Statement-based replication.   First, the triggers that exist on a source must be re-created on the replica server. Once this is done, the replication flow works as any other standard DML statement that participates in replication. For example, consider a table  EMP  that has an  AFTER  insert trigger, which exists on a replication source server. The same  EMP  table and  AFTER  insert trigger exist on the replica server as well. The replication flow would be: 2. The  AFTER  trigger on  EMP  activates. 3. The  INSERT  statement is written to the binary log. 1. An  INSERT  statement is made to  EMP . 4. The replica picks up the  INSERT  statement to  EMP  and executes it. 5. The  AFTER  trigger on  EMP  that exists on the replica activates. Row-based replication.   When you use row-based replication, the changes caused by executing the trigger on the source are applied on the replica. However, the triggers themselves are not 5240