前阵回收生产帐号的访问范围，即之前是xxx@"%"的帐号命名方式，修改成若干个以前端应用部署的机器IP为准，修改成xxx@"IP address"。尽量减少不可信客户端连接数据库的情况发生，加强数据安全。

    但是回收xxx@"%"帐号后发现，生产一子系统一直报错，xxx@"%"帐号不存在的异常。一开始通过检查生产代码的jdbc数据库连接串的配置，发现地址配置成服务器的主机名。怀疑是由于域名被错误解析成外网的IP地址导致，将其修改为内网的IP后重新发版本后仍然存在相同报错。

    后来经过排查后最终发现，由于该子系统还采用触发器，只不过之前写触发器的时候没有定义definer，导致该触发器的definer默认为当前编写该触发器的用户，即：xxx@"%"。

    原来，mysql在删除用户的时候，只会影响到mysql系统库的user表、db表和tables_priv表，而该用户创建的触发器是不会被连带删除掉的，因为触发器的信息都保存在information.schema库的triggers表里面。所以，其他普通用户（没有管理员权限）想要调用其他用户的触发器的时候，就会报错。

    问题定位出来了，就容易解决了：

    1、删掉原先的xxx@"%"的触发器，重新定义definer为xxx@"IP address"的触发器

    2、普通帐号能调用触发器，需要配置triggers的权限，要不会报trigger权限报错。

    总结一下:

    数据库之所以为数据库，就是其存储数据和检索数据的能力强大，虽然数据库也有触发器、自定义函数和存储过程这类functions，但是functions的执行是牺牲了数据库部分性能来实现的。而且也会导致前端应用同后端服务紧耦合，前端有变更，后续服务也要跟着变。所以，除非是一些特殊的场景如BI、数据分析等，一般生产环境都禁用trigger、functions和 stored procedure。将其功能实现在代码层面，减少数据库的负载。