越來越多的網際網路企業在使用postgresql資料庫，我們也不例外。接下來分享乙個反覆授權排查許可權消失的案例。
發現問題
昨天開發請我建立了乙個唯讀使用者abc_tmp_test使用者，並且將mkl_rw使用者下的32個表授權給唯讀使用者用。ok，請簡單輕鬆的乙個需求，很快就完成了。
但是今天開發來和我說，昨天授權的幾個表中，有部分表還是沒有許可權去讀取，讓我幫忙看看。
排查問題
第一次授權
一開始，我以為是昨天遺漏了，先道了乙個歉，再次進行了授權，授權完成之後，檢查了32個表，都能被唯讀使用者查詢，於是放心的告訴開發，昨天的所有表都已經授權好了，我也檢查過一次了。這次肯定不會漏了。
萬萬沒想到，半小時後，開發來和我說，不行，還是有其中幾個表沒有許可權。我之前的連線還沒斷開，再次跑了一遍之前的檢查語句，確實沒有許可權了。臥槽？這是咋回事？資料庫中有雷鋒了？
第二次授權
我再次授權了一次，並且檢查了information_schema.table_privileges，確認了再次授權後，是新增了32行記錄。這次我沒有先通知開發，說已經授權完成了，而是過了一會，我再次去查，變成了28行，又過了一會，變成了16行！
也就是我授權的32個表的select許可權給唯讀使用者，過一段時間之後，這32個表中的一些表的許可權會慢慢消失！而且消失許可權的表，也沒有發現先授權的先消失，後授權的後訊息的規律，但是可以發現最終剩下的，就是那16個表。我開始懷疑起人生了……
難道是pg中授權的表的數量有限？不能超過16個？也沒查到相關的引數啊。
難道是那16個表有什麼特殊設定？從建表語句中也沒看到啊。
難道授權之後需要checkpoint刷盤？測試了checkpoint還是一樣丟許可權。
難道真的有雷鋒出現啊。還說什麼pg和oracle一樣牛，一樣穩定，連基本的授權都會丟。
正在逐個檢查引數之際，同事通過檢查log，發現了drop table的語句……
測試模擬
原來如此，這個案例，可以用下面的測試過程模擬出來了：
是的，如果table被drop了之後，再次重建，此時原本授權給唯讀使用者的許可權，也會消失
向開發確認，是否有drop之後重建表的操作，開發確認，有段程式確實會定期的逐個drop表後重建表！！
為什麼要進行drop表之後重建表的操作？開發說是通過呼叫框架清理資料，框架就是這麼幹的。
ok，明白了目的是為了清理資料，而不涉及到表結構的修改，那麼其實用truncate來清理就可以了。如下測試，許可權不會丟。
最終，開發修改了**，再次授權那32張表之後，許可權不再慢慢消失了。
總結教訓
1. 大千世界無奇不有，資料庫中沒有雷鋒，而是有各種萬萬沒想到的邏輯。
2. 幸虧我們在建庫的時候，建庫標準要求設定了log_statement=ddl, 才能在log中發現線索。（其實我們oracle和pg的建庫標準，都設定了記錄ddl）
原文發布時間為：2018-01-24
資料和雲
Pg資料庫新增唯讀使用者。
今天pg資料庫需要新增乙個唯讀使用者，由於在pgadmin4中無法新增，遂用sql新增，遇到了乙個大坑，很基礎的問題，只怪自己學藝不精，一次提醒自己 注意 postgresql資料庫對大小寫不敏感！create user test2 with encrypted password test2 alt...
檢視MYSQL資料庫中所有使用者及擁有許可權
1.新建使用者。登入mysql mysql u root p 密碼 建立使用者 mysql insert into mysql.user host,user,password values localhost phplamp password 1234 重新整理系統許可權表 mysql flush ...
使用者 角色 許可權資料庫設計
分類 linux 許可權管理 許可權管理，主要是人員和許可權之間的關係，但是如果讓人員直接和許可權打交道，那麼許可權的賦值 許可權的撤銷以及許可權的變動會非常的麻煩，這樣引入了，角色，給角色賦許可權，然後給使用者分配角色。這個設計主要涉及6張表，使用者表,用於儲存使用者的所有資訊 許可權表，用於儲存...