通常專案的倉庫上很多授權只需要到庫級別即可，因為每天每刻都會產生新的表或洗掉，要求授權至表級別，除非表名很少變化，否則會造成極大的管理作業量。但是由于安全要求，也存在要求表級別需求的。這時候如果表較多，比如千萬級別，授權表每次查詢回應較忙。通常會造成很多用戶使用資料庫時，經常遇到卡頓現象。因為每個用戶每做一個操作，資料庫都會校驗其是否存在權限。
我們知道庫級別的授權保存在gbase.db上，一般專案上庫的數量只有幾十個，一般不會超過千個級別。就是說gbase.db的授權記錄數只有千行級別一下，權限查詢時，回應通常漲毫秒級別。用戶的權限校驗程序中不會出現卡頓感知。而表級別的授權是保存在gbase.tables_priv上，表授權太多時就會造成表的回應時間過長。客觀上不可避免，如千萬級別的表，不管什么資料庫，什么引擎，精確查詢一次耗時都不會少于秒級別。而就是這個秒級別的查詢回應，會造成用戶每次操作前，都會有明顯的卡頓感知。那有什么辦法解決嗎？ 說實在的，方法并不是很有效。但可以通過以下方法優化：
1）盡量控制表級別授權數量。加大表洗掉后，回收權限記錄，盡最大努力減少gbase.tables_priv的行數。
2）通過修改引數，讓tables_priv表填充到記憶體，提高該表查詢性能。如修改gcluster的組態檔，增加以下配置
key_buffer_size = 512M
table_open_cache = 16384
table_definition_cache = 16384
修改gnode的組態檔，增加以下配置
key_buffer_size = 512M
table_open_cache = 16384
table_definition_cache = 16384
3）需要天津南大通用研發優化gbase.tables_priv表的引擎，據了解目前GsSYS對這種場景并不擅長。
4）提供性能較好的管理主機，通過硬體條件的升級，來提高該表的查詢效率。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/284750.html
標籤：其他數據庫