Source code editor
What Is Ajax
↑
Questions
26.5.1: Where can I find the documentation for MySQL 5.0 triggers?
26.5.2: Is there a discussion forum for MySQL Triggers?
26.5.3: Does MySQL 5.0 have statement-level or row-level triggers?
26.5.4: Are there any default triggers?
26.5.5: How are triggers managed in MySQL?
26.5.6: Is there a way to view all triggers in a given database?
26.5.7: Where are triggers stored?
26.5.8: Can a trigger call a stored procedure?
26.5.9: Can triggers access tables?
26.5.10: Can triggers call an external application through a UDF?
26.5.11: Is possible for a trigger to update tables on a remote server?
26.5.12: Do triggers work with replication?
26.5.13: How are actions carried out through triggers on a master replicated to a slave?
Questions and Answers
26.5.1: Where can I find the documentation for MySQL 5.0 triggers?
See Chapter 18, Triggers.
26.5.2: Is there a discussion forum for MySQL Triggers?
Yes. It is available at http://forums.mysql.com/list.php?99.
26.5.3: Does MySQL 5.0 have statement-level or row-level triggers?
In MySQL 5.0, all triggers are FOR
EACH ROW
— that is, the trigger is activated
for each row that is inserted, updated, or deleted. MySQL
5.0 does not support triggers using
FOR EACH STATEMENT
.
26.5.4: Are there any default triggers?
Not explicitly. MySQL does have specific special behavior
for some TIMESTAMP
columns, as well as
for columns which are defined using
AUTO_INCREMENT
.
26.5.5: How are triggers managed in MySQL?
In MySQL 5.0, triggers can be created using the
CREATE TRIGGER
statement, and dropped
using DROP TRIGGER
. See
Section 18.1, “CREATE TRIGGER
Syntax”, and
Section 18.2, “DROP TRIGGER
Syntax”, for more about
these statements.
Information about triggers can be obtained by querying the
INFORMATION_SCHEMA.TRIGGERS
table. See
Section 20.16, “The INFORMATION_SCHEMA TRIGGERS
Table”.
26.5.6: Is there a way to view all triggers in a given database?
Yes. You can obtain a listing of all triggers defined on
database dbname
using a query on the
INFORMATION_SCHEMA.TRIGGERS table such as the one shown
here:
SELECT TRIGGER_NAME, EVENT_MANIPULATION, EVENT_OBJECT_TABLE, ACTION_STATEMENT
FROM INFORMATION_SCHEMA.TRIGGERS
WHERE TRIGGER_SCHEMA='dbname
';
For more information about this table, see
Section 20.16, “The INFORMATION_SCHEMA TRIGGERS
Table”.
You can also use the SHOW TRIGGERS
statement, which is specific to MySQL. See
Section 13.5.4.26, “SHOW TRIGGERS
Syntax”.
26.5.7: Where are triggers stored?
Triggers are currently stored in .TRG
files, with one such file one per table. In other words, a
trigger belongs to a table.
In the future, we plan to change this so that trigger
information will be included in the
.FRM
file that defines the structure of
the table. We also plan to make triggers database-level
objects — rather than table-level objects as they are
now — to bring them into compliance with the SQL
standard.
26.5.8: Can a trigger call a stored procedure?
Yes.
26.5.9: Can triggers access tables?
A trigger can access both old and new data in its own table. Through a stored procedure, or a multiple-table update or delete statement, a trigger can also affect other tables.
26.5.10: Can triggers call an external application through a UDF?
No, not at present.
26.5.11: Is possible for a trigger to update tables on a remote server?
Yes. A table on a remote server could be updated using the
FEDERATED
storage engine. (See
Section 14.7, “The FEDERATED
Storage Engine”).
26.5.12: Do triggers work with replication?
Triggers and replication in MySQL 5.0 work in the same wasy as in most other database engines: Actions carried out through triggers on a master are not replicated to a slave server. Instead, triggers that exist on tables that reside on a MySQL master server need to be created on the corresponding tables on any MySQL slave servers so that the triggers activate on the slaves as well as the master.
26.5.13: How are actions carried out through triggers on a master replicated to a slave?
First, the triggers that exist on a master must be
re-created on the slave 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
master MySQL server. The same EMP
table
and AFTER
insert trigger exist on the
slave server as well. The replication flow would be:
An INSERT
statement is made to
EMP
.
The AFTER
trigger on
EMP
activates.
The INSERT
statement is written to
the binary log.
The replication slave picks up the
INSERT
statement to
EMP
and executes it.
The AFTER
trigger on
EMP
that exists on the slave
activates.