最近碰到了一個奇怪的權限問題，問題的背景是業務同學反饋在下班后，有一個數據表出現了阻塞，導致后續的業務流程都產生了擁堵，在對這個問題進行分析發現，業務同學所謂的擁堵，阻塞是數據庫連接出了問題。當然我們進行了一些深入的溝通，對整個問題的情況有了一個更為清晰的了解。
6:30左右，業務同學發現程序端產生了阻塞，程序端正在處理的操作是一個create table的操作。
6:40左右，業務同學嘗試通過客戶端工具連接到數據庫來手工執行，但是發現連接超時，根據業務同學反饋，之前是能夠正常連接的。
6:50左右，業務同學開始呼叫DBA進行處理。
7:00左右，DBA就位后，什么都沒做，就魔法般的解決了問題。
對于業務同學的印象，是數據庫不夠穩定，因為另外一套環境也出現了類似的問題，這是一個很糾結的情況，我們如同哆啦A夢般的存在，但是實際上什么都沒有做就解決了問題。
當然在我的職業生涯中，對待問題我是不相信神奇的力量，事出有因，我希望找到那些看起來簡單的問題的答案。
從業務同學的反饋時間點開始，我嘗試找到一些相關的日志來看看，從數據庫的處理來看，是不大可能阻塞DDL中的create操作的，無論服務器壓力大小，這算是DDL里面最正常的需求了，絕對不應該阻塞幾十分鐘。
幸運的是，我很快找到了相關的binlog日志，簡單解析之后，看到了下面的內容。
從內容來看，情況和業務同學反饋的時間點是吻合的，業務邏輯會自動創建相關的時間表，而下一次create則是在20多分鐘之后，這里的問題就來了，為什么創建兩張表的過程中會有這些權限處理的語句出現?
看這些權限處理的語句還是比較規范的，而且從執行日志來看不大像是人工執行的，因為整個權限的處理涉及的語句條數還比較多，從執行上來看，像是工具生成的。
我查看了下相關時間范圍內的工單數據，發現在那個指定的時間段里，確實有同事在處理幾個相關的工單，帶著這個信息和同事確認，才發現這兩件看起來不相關的事情還是有關聯的。
業務同學反饋，有兩套環境都出現了類似的問題，和工單數據比對發現，情況是完全相符的，在出現問題的時間段里產生了阻塞。
我們來仔細看一下這條語句：
GRANT USAGE ON *.* TO 'srv_datasync_rwh'@'192.168.18.%' IDENTIFIED WITH 'MySQL_native_password' AS '*5EEBC522DE487B0D5C2506C65412F9C337F70C40'
這條語句是對于192.168.18端的客戶端開通相應的權限，而這個grant語句其實是類似MySQL 5.7的create user語句，帶著這個問題繼續下鉆，發現原來這個數據庫中本身是存在用戶'srv_datasync_rwh'@'192.168.18.%' 的，在這里，相當于工具重新生成了完整的授權語句，對已經存在的用戶進行了重新授權，這個操作的代價有點類似于權限重置。
而這個問題在測試環境中模擬是直接復現不了的，整個問題和觸發的上下文環境也有相關性，同時對涉及到權限處理的完整過程中產生了額外影響，有點類似于在購物網站中，一邊在購物下單，另一邊在同時做密碼重置，這是一種較為模糊的臨界狀態。
總體來說，這個權限問題還是相對可控的，我們需要修復運維工具自動生成的語句的邏輯，對于5.7版本的使用create user，grant這種組合授權模式。
個人新書 《MySQL DBA工作筆記》
