数据库触发器详解(7)

/*。。。其余部分逻辑省略*/
END IF;
END;
 
这个触发器程序有点长，可以单看飘黄的两句，即更新操作满足第一个条件执行飘黄语句时，触发器的行为。触发器是建立在test_info表上的，飘黄语句中可以看到，也需要查询wext2表。
 
执行如下sql1：
 
Update test_info a, wext2 b set a.th=(a.th+1), a.w4=(a.w4&8), b.wl=NULL where a.wid=b.wid and a.wid=142394379;
 
可以看到sql中既修改了test_info2表，同时修改了wext2表，程序原意是触发得到wext2表wl字段修改后的新值（即NULL）；不过实验得到，执行上述sql后，触发器程序查询到的wurl是sql修改之前的旧值。
 
再执行下面类似sql2：
 
Update wext2 a, test_info2 b set b.th=(b.th+1), b.w4=(b.w4&8), a.wl=NULL where a.wid=b.wid and a.wid=142394379;
 
实验的到，执行上述sql后，触发器程序查询到的wurl是sql修改之后的新值。
 
【原因】原因当然与sql中的别名a，b无关，而是和wext2表和test_info表的书写顺序有关。如本文3.4部分所述，一条sql涉及多个表的update操作时，数据表字段、触发器执行顺序是mysql源码包装过的。在执行上述sql1时，先执行test_info的更新，然后是after触发器，最后是wext2的更新，也就是说，在执行after触发器时，wext2还没有进行更新，所以触发得到的是旧值。而执行sql2时，先执行wext2更新，然后是test_info更新，最后是after触发器，也就是说，在执行after触发器时，wext2已经更新完毕，所以出去得到的是新值。
 
引起上述现象是顺序关系的，无论该表是否支持事务。在使用复杂的sql时，由于有些复杂的sql是mysql自己定义的，所以存在不确定性，存在风险，使用简单的sql比较可控。
 
5.2   案例2 mysql5.0.19版本修改表结构后触发器失效
 
【现象】userpref表上建有after类型触发器，修改userpref表的外键关联后，在userpref表中的新增记录没有触发下来，即触发器失效。
 
【原因】mysql5.0.19修改表结构是，触发器消失。这是mysql5.0.19的一个bug，在创建触发器时，会把触发器的内容保存在information_schema.TRIGGERS表中，同时在var目录下创建触发器的数据库目录下创建一个触发器名称为前缀，以TRN为后缀的文件，当修改触发器的表时，information_schema.TRIGGERS表的内容会删除，导致触发器消失。
 
在mysql5.0.45版本中，这个bug已经被修复。Mysql5.0.45版本的触发器，无论是修改表的索引、外键，还是改变表字段，触发器都不会失效。
 
5.3   案例3 删除数据表后触发器失效
 
【现象】联调环境中存在dbA?dbB，主库dbA上没有触发器，在从库dbB上的FC_Word.wnegative表，FC_Word.wbuget 表上建有触发器；触发器开始运行正常，期间没有对从库的任何直接操作，有一日发现对wnegative表上的修改无法触发。查看从库状态，同步正常；用select TRIGGER_NAME from information_schema.TRIGGERS发现wnegative表上的触发器消失了；在var/FC_Word目录下也没有wnegative的.TRN文件，wnegative表上的触发器不见了。
 
【分析】查找dbB的查询日志，发现有一条：
 
100223 18:27:45 135939 Query       DROP TABLE IF EXISTS `wnegative`
135939 Query       CREATE TABLE `wnegative` (
KEY `Index_wnegative_planid` (`planid`),
KEY `Index_wnegative_unitid` (`unitid`)
135939 Query       /*!40000 ALTER TABLE `wnegative` DISABLE KEYS */