MySQL的存儲過程，沒錯，看起來好生僻的使用場景。問題源于一個開發同學提交了權限申請的工單，需要開通一些權限。
本來是一個很正常的操作，但在我來看是比較著急且緊迫的，說來慚愧，忙著方向規劃和開發的事情，這個基礎的操作功能竟然給忽略了，所以看到目前的一些實現方式，還是希望能夠做一些細小的事情把這些重復性的工作給解放了。
當然我決定把一些基礎性的工作接過來，一方面是給同事減壓，另一方面是在做一個完整的體驗，因為很多需求和痛點通過實踐是能夠很容易捕捉到重點的，如果我覺得不合理，那么這個過程中勢必會有一些改進的地方。比如部署安裝，比如權限開通。數據庫的權限開通就是一個相對典型的案例，而存儲過程的權限開通甚至都有點讓人懷疑人生了。
問題的場景還是很基礎的，開發同學需要開通一些基礎的權限，在標記權限的時候聲明需要增刪改查的權限，還有DDL的權限，比如drop,alter,create等等。看到這里，我就感覺不太妥了，什么樣的操作竟然需要這么大的權限呢。
簡單聲明了下立場，開發同學的想法是能夠方便管理，于是乎我就直接招過去了，簡單溝通下，其實發現他們的需求場景還是很常規的，他們需要動態創建一些日表，那么需要create權限在評估之后是可以給與的，而對于一般的用戶而言，create的權限是不建議開放的，主要的出發點就是能夠對SQL進行一些基本的審核，哪怕是人工審核還是平臺審核都是一個需要的過程。所以溝通了一圈發現，開通的權限就可以迅速裁剪，對他們而言，修改存儲過程的邏輯也是需要的，因為在一些特定的場景下，他們對邏輯的控制希望能夠更加靈活。
好了，基礎的背景介紹完了。賦予基本的表的權限，賦予存儲過程的權限，存儲過程的這個地方需要注意一個重要的點是SQL SECURITY，默認創建是definer，如果需要開放給其他的用戶調用，則建議是設置為invoker.
所以很簡單的一句：
| grant execute,alter procedure on xxx.xxx to xxx@'xxxx'; |
但是很不幸的，開發同學反饋，他們通過SQLyog或者是Navicator打開的時候，竟然看不到存儲過程的內容。
因為我們沒有select procedure或者view procedure的權限，所以我們幾乎再無從干預了。
使用命令行的方式能夠復現出這個問題:
沒有存儲過程的實質性內容。在那兒折騰了好一會，發現是個老問題了，10多年前的老問題了。
https://bugs.mysql.com/bug.php?id=20235
問題的解決其實很簡單，就是需要這樣一句:
| grant select on mysql.proc to xxxx@'xxxx'即可 |
