前陣回收生產帳號的訪問範圍，即之前是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。將其功能實現在代碼層面，減少數據庫的負載。