教你調整服務器變量 適應企業個性需求
不同的企業，對于數據庫可能會提出不同的個性化需求。如日期顯示的格式等等。為了滿足不同企業在這方面的要求，在MySQL數據庫中提出了服務器變量的概念。通過對這些變量進行調整，數據庫管理員可以建立起一個符合企業實際情況的應用環境。在這里，筆者就結合自己的工作經驗，談談如何對服務器變量進行調整，以及相關的注意事項。
一、查看系統現有變量的值
數據庫管理員如果需要對服務器變量進行調整，首先需要對現有的變量以及相關值有所了解。用戶可以通過使用命令show variables來查看系統中可用的變量以及默認值。不過系統的變量有200多個，查找起來比較麻煩。為此，用戶可以通過使用like查詢條件加上通配符來進行快速查找。如下圖所示，筆者使用了’date%’，系統就會列出所有以date開頭的變量名。這與SQL語句中的查詢條件非常的類似。
使用通配符與Like關鍵字可以幫助數據庫管理員迅速定位相關的變量。不過在使用通配符時，需要注意，兩邊的單引號不能夠忘記。否則的話，系統就會報錯。其次，在這個命令行環境下，對于大小寫是不敏感的。也就是說，’date%’與’Date%’兩個是等價的。這對于一些大小寫不分的數據庫管理員來說，是一個不錯的特性。不過在輸入條件語句時，有一個細節需要注意，即空格。在查詢時，系統不會自己過濾空格。’date%’與’ date%’兩個語句有什么區別嗎?粗粗的一看，好像是相同的。其實兩個是不同的內容。后面一個在date前面有一個空格，而***個沒有。此時從數據庫中得到的結果也是截然相反。由于系統變量前面都沒有空格，所以采用后面一個語句，將查不到任何可用的變量。為此在查詢時，需要注意空格對查詢語句的影響。
二、區分全局變量與會話變量
在開發環境中，變量一般會有全局變量與局部變量的區分。兩者核心的差異就是作用域不同。對于MySQL數據庫來說，也有這方面的定義。MySQL數據庫的變量可以分為全局變量與會話變量。兩者的主要區別也在于作用域的不同。
全局變量，顧名思義，會影響到服務器的全局操作。在數據庫服務器啟動的過程中，系統會將所有全局變量初始化為默認值。當然，數據庫管理員可以根據需要，在選型文件或者命令行中指定相關的選項來更改這些默認值。即使在服務器啟動之后，數據庫管理員仍然可以通過執行Set Global 變量名的方式來更改動態全局變量。
會話變量只是針對某個特定的會話有效，而不會對其他會話產生影響。服務器還會為每個客戶端連接維護會話變量。在連接時，如果沒有為某個特定的會話設置值的話，系統會用全局變量來初始化會話變量。同樣，用戶也可以通過Set Session 變量名來更改動態會話變量。
在對全局變量或者會話變量進行更改時，需要注意權限問題。如果對全局變量進行更改，則需要注意，用戶必須要有Super權限。但是如果對會話變量進行更改的話，則默認情況下不需要特殊權限。也就是說，用戶可以更改自己會話的變量，但是不能夠更改其他客戶的會話變量。不過通常情況下，并不建議用戶更改相關的會話變量。
三、更改后的生效時間
全局變量或者局部變量更改后，什么時候生效呢?這又是數據庫管理員需要關注的內容。在講解這個知識點時，筆者還是需要強調一下，各位要關注全局變量與會話變量的差異。只有掌握這個差異之后，對于變量更改的生效時間才會有更加深刻的認識。
對于全局變量來說，通常情況下，任何訪問全局變量的客戶端都可以看見對全局變量的更改。當全局變量進行更改時，它只影響在更改后連接的從該全局變量初始化相應會話變量的客戶端，而不會影響已經連接上的客戶端的會話變量，即使是執行了Set語句來更改也是如此。這主要說明了兩點。一是全局變量的更改，并不像其他系統一樣，需要重啟系統后才會生效。不重新啟動數據庫系統也會生效。二是對于當前已經連接的客戶不會生效，而只會對更改后的新會話有效。為此如果要測試某個全局變量的更改是否生效，數據庫管理員不需要重新啟動服務器，只需要新建一個會話就可以進行測試。測試完成后，如果確定需要使用這個更改，也不需要重新啟動服務器。只需要先關閉當前的所有會話，讓用戶重新建立會話即可。
與此類似，會話變量更改之后，也不需要重新啟動服務器即可生效。不過會話變量又與全局變量不同，其只對自己的會話有效。這也就是說，會話變量更改之后，在當前會話中就會有效。
如果數據庫管理員要同步全部的應用環境，如整個信息化應用采用相同的時間格式，在這種情況下，筆者建議采用全局變量，而不是會話變量。比較會話變量的作用域比較有限。
四、更改后的測試與備份
無論是全局變量還是會話變量，更改后都會有一個測試的過程。對于全局變量更改的測試，筆者建議先采用小范圍內的測試。如更改了日期顯示格式之后，為了測試其有效性，筆者建議數據庫管理員先建立一個新的會話，然后查看更改是否生效。而不要先急著重置所有的會話。如此的話，萬一更改失敗或者不理想，因為不會影響到已連接的會話(只會對更改后的新會話起效)，就可以將不利影響控制在最小的范圍之內。不過這么做還需要控制整個時間。如這個時間間隔拖了很長，如一天24個小時，此時就會出現問題。如財務部門是在更改之前就連結了，而采購部門有一個用戶是在更改之后再連接的。此時兩個不同的用戶導出來的表格上，時間顯示的格式就可能不同。這會造成一定的誤導?？梢?，這個策略有利也有弊。數據庫管理員，應該將這個測試的時間盡量縮短。如果測試的時間比較長的話，那么***再搭建一臺服務器進行測試，而不要在生產服務器上直接進行測試。
另外，對于更改后的配置，***進行獨立的備份。這里的備份并不是對數據庫的整體備份，而是說對配置文件的備份。而且還需要做好詳細的說明。如為什么要進行這個調整、調整的時間點是什么。
為了保持應用前后的一致性，這個調整的時間其實也有講究的。一般情況下，不要在一個工作日的中間進行調整。如中午12點進行調整等等。如此的話，就會導致上午與下午的單據出現混亂。在某些特殊的應用中，可能對這個調整的時間會有更加嚴格的要求。如對于財務軟件的后臺數據庫，則相關全局變量的調整，可能需要考慮到會計期間的問題。其只能夠在月末或者年末進行調整。所以對某個全局變量進行調整時，因為會對全部用戶產生影響，為此在更改之前，需要征求所有用戶的意見。然后根據企業的實際情況與用戶的要求，選擇一個合適的調整時間。通常情況下，一個比較有經驗的數據庫管理員，會了解更改哪些全局變量會對最終用戶產生影響，而哪些全局變量只是對系統維護有影響。然后就會根據需要更改變量的影響范圍，去判斷是否需要經過最終用戶的確認。如果能夠做出這樣的判斷，那是***?？蓪τ脩舻挠绊懡档偷?**程度。
【編輯推薦】
