![](https://images2015.cnblogs.com/blog/699877/201510/699877-20151022210837083-258606076.png)
![](https://images2015.cnblogs.com/blog/699877/201510/699877-20151022211119817-159546285.png)
![](https://images2015.cnblogs.com/blog/699877/201510/699877-20151022211204130-731832925.png)
![](https://images2015.cnblogs.com/blog/699877/201510/699877-20151022220236942-1479929980.png)
![](https://images2015.cnblogs.com/blog/699877/201510/699877-20151022220250677-1478125044.png)
Syntax: CREATE [DEFINER = { user | CURRENT_USER }] TRIGGER trigger_name trigger_time trigger_event ON tbl_name FOR EACH ROW trigger_body trigger_time: { BEFORE | AFTER } trigger_event: { INSERT | UPDATE | DELETE }
1)trigger 只能在表中的数据进行: insert, update, delete 时进行某种处理,也就是说他不能对表上的 DDL 语句进行某种处理!!!!
2)MySQL triggers activate only for changes made to tables by SQL statements. They do not activate for changes in views, nor by changes to tables made by APIs that do not transmit SQL statements to the MySQL Server. 通过视图修改和通过API修改的表的数据时,不会触发trigger
MySQL5.5 主从复制 (触发器,函数,存储引擎,事件处理)说明
mysql5.5 对触发器,函数,存储引擎,事件进行主从复制情况.
一、MySQL主从复制有三种模式.
1.binlog_format = row : 日志中会记录成每一行数据被修改的形式(记录页面),然后在 slave 端再对相同的数据进行修改。
2.binlog_format = statement : 每一条会修改数据的 SQL 都会记录到 master 的 bin-log 中。slave 在复制的时候 SQL 进程会解析成和原来 master 端执行过的相同的 SQL 再次执行。
3.binlog_format = mixed : 这个模式是在5.1.8版本之后, 才有的. mixed是row和statement的混合模式.
二、触发器的主从复制.
A .当binlog_format = statement 或 binlog_format = mixed (使用混合模式用的是statement 方式) 这种模式下复制情况
1. 主从复制的时候,主从触发器都受到definer从句的约束.只有主从上都有这个用户才能正常运行这个触发器.
2. 主服务器上SQL语句传到从服务器上,从服务器再执行SQL语句去触发从服务器的触发器(这里要说明是:主服务器不会把触发后的SQL传递给从服务器).
这里可以看到,传递是原始的SQL语句.
B .当binlog_format = row 或 binlog_format = mixed(使用混合模式用的是row方式) 这种模式下复制情况
1. 主服务器把被修改的页面复制给从服务器,并且这个修改的页面的值是触发后的改变值.
2. 因为这个页面的值是触发后改变的值, 所以在从服务器上可以不需要这个触发器.
3. 删除从服务器上的触发器.一样的可以得到跟主服务器一样的值.
三、存储过程的主从复制
1. 主服务器上的存储过程同样收到definer从句的约束.但是,在复制的时候,从服务上不需要有存储过程
A. 当binlog_format = statement 或binlog_format = mixed (使用混合模式用的是statement 方式) 这种模式下复制情况
可以看到通过系统函数转换后的值复制给从服务器,不需要在从服务器上建立。(注:其实这里是错误的!和文档中的明显不一致,参见最后的总结。)
B .当binlog_format = row 或 binlog_format = mixed(使用混合模式用的是row方式) 这种模式下复制情况(传的都是数据)
四、函数主从复制
A . 当binlog_format = statement 或binlog_format = mixed (使用混合模式用的是statement 方式) 这种模式下复制情况
1. 主从复制的时候,主从触发器都受到definer从句的约束.只有主从上都有这个用户才能正常运行这个函数
2. 主服务器上SQL语句复制从服务器上,从服务器再执行SQL语句再去调用从服务器的函数(主服务器不会把函数的返回值传给从服务器的)
B. 当binlog_format = row 或 binlog_format = mixed(使用混合模式用的是row方式) 这种模式下复制情况(传的都是数据)
1.主服务器会直接把修改过的页面复制给从服务器,从服务器不需要有对应的函数
五、事件主从复制
当事件有用函数,触发器,存储过程时.跟上面的操作情况是一样的.
但有一点不同的是.
在主服务器上建立一个event,当然,在从服务器上也会创建一个event..(默认情况下主event复制到从服务器的event是关闭着的)
1.主服务器上的event
2.从服务器上的event
如果在从服务器,开启事件.不仅主服务器复制过来的SQL语句执行一遍,从服务器上的EVENT也会执行.
(events 没有必要迁移到slave上,默认disable也是正确的。因为master上执行的events也会通过sql或者数据复制到slave上。)
2)存储过程和函数在定义时,有 确定性函数和非确定性函数的分别;比如 uuid(),now()这些函数肯定都是非确定性函数,因为它们每次执行的值是不确定的。所以在master和slave上分别执行会导致数据不一致。所以在基于语句复制的环境中,函数都必须是 确定性的(DETERMINISTIC)。不然就只能采用row复制格式了。
3)在基于statement复制时,trigger中定义的sql语句在执行时,不会传给slave,而仅仅传调用trigger的语句本身。所以不会导致定义在trigger中的sql执行两次。也就是说不会既将调用trigger的语句传给slave,又将在trigger执行时,在trigger中运行的那些sql语句传给slave. 因为这样会导致那些 sql 执行两次。