失败时，after型触发器不会执行。
3.3 如果after类型的触发器程序执行失败，sql会回滚吗？
实验如下：
1）在FC_Word.planinfo中建立after触发器：
DELIMITER |
create trigger trigger_after_planinfo_update
after update
ON FC_Word.planinfo FOR EACH ROW
BEGIN
insert into FC_Output.abc (planid) values (New.planid);
END
|
2）查看：mysql> select showprob from planinfo where planid=1;
+----------+
| showprob |
+----------+
| 2 |
+----------+
3）执行sql：
update planinfo set showprob=200 where planid=1;触发触发器程序；
4）由于不存在FC_Output.abc，after触发器执行失败，提示：
ERROR 1146 (42S02): Table 'FC_Output.abc' doesn't exist
5）再次查看：
mysql> select showprob from planinfo where planid=1;
+----------+
| showprob |
+----------+
| 2 |
+----------+
即修改sql未执行成功。即如果after触发器执行失败，sql会回滚。
这里需要说明一下，上述实验所使用的mysql引擎是innodb，innodb引擎也是目前线上凤巢
系统、北斗系统以及哥伦布系统所使用的引擎，在innodb上所建立的表是事务性表，也就是事务安全的。“对于事务性表，如果触发程序失败（以及由此导致的整个语句的失败），该语句所执行的所有更改将回滚。对于非事务性表，不能执行这类回滚”（摘自mysql使用手册）。因而，即使语句失败，失败之前所作的任何更改依然有效，也就是说，对于innodb引擎上的数据表，如果触发器中的sql或引发触发器的sql执行失效，则事务回滚，所有操作会失效。
3.4 mysql触发器程序执行的顺序
当一个表既有before类型的触发器，又有after类型的触发器时；当一条sql语句涉及多个表的update时，sql、触发器的执行顺序经过mysql源码包装过，有时比较复杂。
可以先看一段mysql的源代码，当SQL中update多表的时候，Mysql的执行过程如下（省去了无关代码）：
/* 遍历要更新的所有表*/
for (cur_table= update_tables; cur_table; cur_table= cur_table->next_local)
{
org_updated = updated
/* 如果有BEFORE 触发器，则执行；如果执行失败，跳到err2位置*/
if (table->triggers &&
table->triggers->process_triggers(thd, TRG_EVENT_UPDATE,TRG_ACTION_BEFORE, TRUE))
goto err2;
/*执行更新，如果更新失败，跳到err位置*/
if(local_error=table->file->update_row(table->record[1], table->record[0])))
goto err;
updated++; // 更新计数器
/* 如果有AFTER 触发器，则执行；如果执行失败，跳到err2位置*/
if (table->triggers &&
table->triggers->process_triggers(thd, TRG_EVENT_UPDATE, TRG_ACTION_AFTER, TRUE))
goto err2;
err:
{
/*标志错误信息，写日志等*/
}
err2:
{
/*恢复执行过的操作*/
check_opt_it.rewind();
/*如果执行了更新，且表是有事务的，做标志*/
if (updated != org_updated)
{
if (table->file->has_transactions())
transactional_tables= 1;
}
}
}
从上面代码可以找到本章开始时抛出问题的答案。
1） 如果before型触发器执行失败，直接goto跳到err2位置，不会执行后续sql语句；
2） 如果sql执行失败，直接goto跳到err位置，不会执行或许的after型触发器；
3） 如过after触发器执行失败，goto到err2位置，恢复执行过的操作，且在事务型的表上做标记。
另外，在使用复杂的sql时，由于有些复杂的sql是mysql自己定义的，所以存在不确定性，使用简单的sql比较可控。
4 Mysql触发器在数据库同步中的表现
4.1 触发器运行失败时，数据库同步会失败吗？
有同步关系如下dbA dbB。初始时同步正常。
1）在dbB上建立触发器：
DELIMITER |
create trigger trigger_after_planinfo_update
after update
ON FC_Word.planinfo FOR EACH ROW
BEGIN
insert into FC_Output.abc (planid) values (New.planid);
END
|
2）在dbA上执行sql，执行成功；
mysql> update planinfo set showprob=200 where planid= 1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
3）由于dbB上没有FC_Output.abc表，触发器会执行失败，这时，检查一下同步状态：
Slave_IO_Running: Yes
Slave_SQL_Running: NO
Last_Errno: 1146
Last_Error: Error 'Table 'FC_Output.abc' doesn't exist' on query. Default database: 'FC_Word'. Query: 'update planinfo set showprob=200 where planid= 1'
可以看到IO线程运行正常，sql线程运行失败，并提示触发器运行失败的错误信息。
回忆一下3.1和3.3所述部分，无论是before部分的触发器还是after类型的触发器，对于innodb引擎，当触发器执行失败时，相应sql也会执行失败，所以数据库同步也会失败。
4.2 创建、删除触发器写bin-log
创建和删除触发器的语句也会写入bin-log里，所以也会如一般的insert，update，delete语句一样同步到下游数据库中，即上游创建触发器，下游也会创建。
这里再引出两个小问题：有同步关系dbA dbB，
1） 在dbA上创建 |