一、針對特定的服務器資源施加限制
在MySQL數據庫中，數據庫管理員可以根據需要對某個帳戶實施資源限制策略。當然，無法做到對全部資源進行限制，實際工作中也沒有這個必要。通常情況下，只需要對如下幾個資源進行限制即可。一是賬戶每個小時可以連接服務器的次數，二是賬戶每個小時可以翻出的更新數，三是每個小時可以發出的查詢數，四是每個帳戶可以同時連接服務器的連接數。通常情況下，這已經可以滿足大部分用戶的需求。
這裡需要注意，以上的限制都是針對特定的帳戶而言，而不是客戶端。如每個帳戶可以同時連接服務器的連接數這個限制，是針對賬戶。如現在一個賬戶可能在同一時間從多個客戶端連接到數據庫服務器。此時客戶端的數量就要大於這個連接數了。為此，用戶需要牢記，筆者這裡談到的資源限制，針對的是賬戶，而不是客戶端。
如果用戶需要查詢某個賬戶是否設置了相關的資源限制，則可以通過如上圖所示的語句進行查詢。如果查詢的值為0，則表示沒有添加任何的限制。如果有非0的數字，則表示添加了相關的限制策略。如上圖所示的結果，表示這個賬戶沒有添加資源使用限制。
二、賬戶資源限制的使用注意事項
在使用這個措施來限制賬戶資源使用時，需要注意，這個策略嚴格限於全局，而不允許管理具體的賬戶。並且，這個策略只限制使用單一賬戶同時連接的數量，而不是客戶端連接後的操作。這種限制措施，在針對互聯網的應用程序非常的有效。
另外在設置這個資源使用限制措施時，還需要注意與用戶賬戶的權限掛鉤。如現在某個用戶只有數據查詢的權限，而在資源使用限制時，卻給其做了“賬戶每小時可以發出的更新數”的限制，這不是脫了褲子放屁嗎?這就在提醒數據庫管理員，在設置資源限制措施時要注意用戶賬戶的權限問題。
多個客戶端的同一賬戶操作，其使用情況會被合並。如現在有一個用戶，其被限制為“賬戶每小時連接服務器的次數”為5次。如果其在一個客戶端上連接了3次，然後再在另外一個客戶端上使用同一個賬戶連接3次，這會被允許呢?答案是否定的。服務器在運行過程中，會統計每個賬戶使用資源的次數。如果賬戶在最後一個小時的連接次數達到限制，那麼這個賬戶的進一步連接就會被限制。類似的，如果賬戶達到查詢或者更新次數的限制，進一步查詢或者更新就會被拒絕。服務器會給出相關的錯誤提示。不過需要注意的是，這個資源的統計是根據每個賬戶來進行的，而不是根據每個客戶端來展開。如筆者上面列舉的這個案例。如果用戶允許每小時連接的服務器次數為5次，那麼這個用戶就不能夠更換客戶端讓這個連接次數增加為10次。這就是MySQL數據庫一種防止舞弊的措施。如果通過客戶端來統計資源的使用情況，就會出現上面這種情形的舞弊。在使用Grant語句來設置資源限制時，可以使用With子句來命名每個要限制的資源和根據每小時計數的限制值。
三、計數器清零
上面資源的統計，其實是通過數據庫內部的一個計數器來完成的。不過在某些特定的情況下，可能需要對這個計數器進行清零的操作。如對某個賬戶設置了資源限制之後，數據庫管理員可能需要進行測試，來判斷這個計數器是否起作用。在進行測試時，就會耗用賬戶的資源。測試完成後給用戶使用時，就需要對這個賬戶對應的計數器來一個清零的操作。否則的話，肯定會受到用戶的抱怨。
在MySQL數據庫中，可以為所有賬戶從全局重設當前的每小時資源使用數量，即重置計數器，或者單獨重設某個特定的賬戶。如果數據庫管理員需要為所有賬戶從全局角度將計數器重置為0，則可以執行Flush User_Resources語句。執行這個語句之後，會將所有賬戶的計數器重置為0。如果需要對某個具體賬戶的計數器進行調整，則這裡可以使用Grant Usage語句來實現。
不過這裡需要注意，計數器重置對賬戶連接數這個限制措施不會有影響。因為這個並不是按小時，而是指同一時間一個賬戶的連接數量。通常情況下，當服務器重新啟動時所有的計數器都會清零。
四、具體應用解析
現在企業有一個基於B/S架構的OA系統。為了提高應用系統的安全與性能，就要限制資源的使用。如筆者為了防止病毒或者木馬通過多次連接服務器，來消耗服務器的資源。筆者就做了一個“賬戶每小時可以連接服務器的次數”的限制措施。賬戶每小時最多可以連接服務器10次，也就是說平均沒6分鐘一次。其實這已經足夠了。正常情況下，用戶連接上服務器之後，一般是不會再斷開了。也就是說，一小時就可能連接服務期一次。如果這個連接的次數設置的過多，或者不加限制，反而會給病毒或者木馬程序可乘之機。
