隨著負載和文件大小的增長，性能往往會降低。記住以下的7個關鍵點，讓你的MySQL輕松保持平穩(wěn)運行。
測量應用程序的方式之一是測量它的性能。用戶體驗是衡量應用程序性能的一個指標，這就意味著用戶是否能在合理的時間內(nèi)獲得所需的內(nèi)容。
有很多研究都表明，性能對用戶的行為有很大的影響：
79%的用戶表示不太可能再次打開一個緩慢的網(wǎng)站；
47%的用戶期望網(wǎng)頁能在2秒鐘以內(nèi)加載；
40%的用戶表示如果加載時間超過三秒鐘，就會放棄這個網(wǎng)站；
頁面加載時間延遲一秒可能導致轉(zhuǎn)換損失7%，頁面瀏覽量減少11%。
無論標準是什么，都要保持良好的應用性能是非常必要的。否則，用戶就會抱怨(或轉(zhuǎn)到另一個應用程序)。影響應用程序性能的一大因素就是數(shù)據(jù)庫性能。應用程序、網(wǎng)站和數(shù)據(jù)庫之間的交互對應用程序性能至關重要。
這種交互的核心部分是應用程序如何查詢數(shù)據(jù)庫以及數(shù)據(jù)庫對請求的響應。無論從哪一方面來說，MySQL都是最受歡迎的數(shù)據(jù)庫管理系統(tǒng)之一。很多企業(yè)正在將MySQL(和其他開源數(shù)據(jù)庫)作為其生產(chǎn)環(huán)境中的數(shù)據(jù)庫解決方案。
有很多配置MySQL的方法可以幫助確保您的數(shù)據(jù)庫快速響應查詢，并且減少應用程序性能下降。
以下是幫助您優(yōu)化MySQL數(shù)據(jù)庫性能的一些重要技巧。
MySQL優(yōu)化關鍵1：了解如何使用EXPLAIN
對于數(shù)據(jù)庫，您做出的最重要的兩個決策分別是：
設計應用程序?qū)嶓w之間的關系如何映射到表(數(shù)據(jù)庫模式)中
設計應用程序如何以所需格式(查詢)獲取所需的數(shù)據(jù)。
復雜的應用程序可能具有復雜的查詢和模式。如果您要獲得應用程序所需的性能和擴展性，不能僅僅直觀的來了解查詢是如何執(zhí)行的。
您應該學習如何使用EXPLAIN命令。此命令向您展示了應該如何執(zhí)行查詢，并讓您深入了解可以預期的性能以及查詢?nèi)绾坞S著數(shù)據(jù)大小的變化而縮放。
類似于MySQL Workbench的工具，都可以為您顯示EXPLAIN輸出，但您仍然需要學習基礎知識以理解它。
EXPLAIN命令提供輸出有兩種不同格式：舊式表格格式和更現(xiàn)代化的結(jié)構(gòu)化JSON文檔，后者能提供更多的細節(jié)(如下所示)：
對于一個組件來說應該關注的是“查詢成本”。查詢成本是指基于許多不同的因素上，MySQL在查詢執(zhí)行的總體成本考慮了該特定查詢成本。
簡單查詢的查詢成本通常低于1000。成本在1000到100000之間的查詢被視為中等成本查詢，如果您每秒只運行數(shù)百個這樣的查詢(而不是數(shù)萬)，通常認為是快速的。
超過100000的查詢認為是高成本查詢。通常，當您是系統(tǒng)上的單個用戶時，這些查詢?nèi)匀贿\行得很快，但是必須要考慮到在交互式應用程序中使用這些查詢的頻率(尤其是隨著用戶數(shù)量的增長)。
雖然這都是一些大致的數(shù)字，但是它們表現(xiàn)出了一般原則。體系結(jié)構(gòu)和配置可能會影響系統(tǒng)的處理查詢工作負載。
確定查詢成本的主要因素是查詢是否使用正確索引。 EXPLAIN命令可以告訴您查詢是否要用索引。這就是為什么學習使用EXPLAIN 的重要原因。
MySQL優(yōu)化關鍵2：創(chuàng)建正確的索引
索引可以減少查詢必須掃描數(shù)據(jù)量來提高查詢性能。 MySQL中的索引用于加速數(shù)據(jù)庫中的訪問，并幫助實施數(shù)據(jù)庫約束(例如UNIQUE和FOREIGN KEY)。
數(shù)據(jù)庫索引很像書籍索引。它們保存在自己的位置，并且包含已經(jīng)在主數(shù)據(jù)庫中的信息。它們是一種數(shù)據(jù)所在的參考方法。索引不會更改數(shù)據(jù)庫中的任何數(shù)據(jù)，只是指向數(shù)據(jù)的位置。
在系統(tǒng)運行查詢中，您應該始終查看索引。
一個缺失的索引也可能會使數(shù)據(jù)庫運行速度速度降低。但要不要添加不需要的索引！不必要的索引會減慢數(shù)據(jù)庫運行速度。
MySQL優(yōu)化關鍵3：不要使用默認模式！
像任何軟件一樣，MySQL有許多可配置的設置，可用于修改行為。但是管理員忽略了許多可配置的設置，始終在默認模式下運行。
為了獲取MySQL的最佳性能，了解可配置設置是非常重要的，更重要的是將它們設置為最適合您的數(shù)據(jù)庫環(huán)境。
默認情況下，MySQL適合于小規(guī)模開發(fā)安裝，而不是用于生產(chǎn)規(guī)模。您通常要配置MySQL，以使用可用的所有內(nèi)存資源，并允許應用程序所需的連接數(shù)。
這里有三個MySQL性能調(diào)優(yōu)設置：
(1) innodb_buffer_pool_size：緩沖池是緩存數(shù)據(jù)和索引的地方。這是使用具有大量RAM的系統(tǒng)作為數(shù)據(jù)庫服務器的主要原因。如果您只運行InnoDB存儲引擎，通常會為緩沖池分配大約80%的內(nèi)存。如果運行非常復雜的查詢、有大量的并行數(shù)據(jù)庫連接或者有大量的表，那么可能需要將此值降低一個級別，為其他的運行分配更多內(nèi)存。
當您設置InnoDB緩沖池大小時，不要將其設置得太大否則會導致互換。這絕對會破壞數(shù)據(jù)庫性能。一個簡單的檢查方法是查看Percona監(jiān)控和管理系統(tǒng)概述圖中的交換活動：
如圖所示，一些交換是非常頻繁的。如果您看到持續(xù)的交換活動為每秒1MB或更多，那么將需要減少緩沖池大小(或其他內(nèi)存使用)。
如果第一次沒有獲得innodb_buffer_pool_size的正確值，不用擔心。從MySQL 5.7開始，可以動態(tài)更改InnoDB緩沖池的大小，無需重新啟動數(shù)據(jù)庫服務器。
(2) innodb_log_file_size：這是一個單獨的InnoDB日志文件大小。默認情況下，InnoDB使用兩個值，以便您可以將此數(shù)字加倍，以獲取循環(huán)重做日志空間的大小，確保事務持久運行。這也優(yōu)化了應用對數(shù)據(jù)庫的更改。設置innodb_log_file_size是一個需要權衡的問題，分配的重做空間越大，寫入密集型工作負載的性能越好，但如果系統(tǒng)遇到電源丟失或其他問題，花費的恢復時間也越長。
如何知道MySQL性能受當前InnoDB日志文件大小的限制呢？可以通過查看實際使用的重做日志空間來判斷。最簡單的方法是查看Percona Monitoring and Management InnoDB Metrics儀表板。在下圖中，InnoDB日志文件大小不夠大，因為使用的空間非常接近可用的重做日志空間(由紅線表示)。日志文件大小應至少比用于保持系統(tǒng)執(zhí)行最佳性能的空間大20%。
(3) max_connections：大型應用程序通常需要比默認的連接數(shù)量多得多。與其他變量不同，如果不正確設置，就不會出現(xiàn)性能問題(本質(zhì)上)。相反，如果連接數(shù)量不足以滿足應用需求，那么您的應用程序?qū)o法連接到數(shù)據(jù)庫(這對用戶來說看起來就像停機了)。獲取這個政權變量是非常重要的。
在多個服務器上運行許多組件的復雜應用程序中，可能難以知道需要多少連接。但幸運的是，MySQL可以很容易地看到在峰值操作時使用了多少個連接。通常，為確保應用程序使用的最大可用連接數(shù)比最大連接數(shù)至少大30%。查看這些數(shù)字的簡單方法是在Percona監(jiān)控和管理的MySQL概述儀表板中使用MySQL連接圖。下圖顯示了一個健康的系統(tǒng)，其中有很多額外的連接可用。
要記住的一點是，如果您的數(shù)據(jù)庫運行緩慢，應用程序通常會創(chuàng)建過多的連接。在這種情況下，您應該處理數(shù)據(jù)庫性能問題，而不是簡單地允許更多的連接。過多的連接可能會使基礎性能問題更糟。
(注意：當您將max_connections變量設置為顯著高于默認值時，通常需要考慮增加其他參數(shù)，如表緩存的大小和MySQL允許的打開文件數(shù))
MySQL優(yōu)化關鍵4：將數(shù)據(jù)庫保存在內(nèi)存中
近年來，我們看到了固態(tài)硬盤(SSD)的轉(zhuǎn)型。即使SSD比旋轉(zhuǎn)硬盤驅(qū)動器要快得多，但是它們?nèi)匀慌cRAM中的數(shù)據(jù)不兼容。這中差異不僅來自于存儲性能本身，還來自數(shù)據(jù)庫在從磁盤或SSD存儲中檢索數(shù)據(jù)時必須執(zhí)行的其他工作。
隨著硬件改進，無論您是在云端運行還是管理自己的硬件，都越來越有可能將您的數(shù)據(jù)庫存儲在內(nèi)存中 -。
更好的消息是，您不需要將所有數(shù)據(jù)庫都裝入內(nèi)存，只需將常訪問的工作數(shù)據(jù)集合放到內(nèi)存中即可。
檢查數(shù)據(jù)庫在穩(wěn)定狀態(tài)下運行的I / O數(shù)量(通常在啟動后幾個小時)。下圖您可以在Percona監(jiān)控和管理的InnoDB Metrics儀表板上的InnoDBI / O。
在上圖中，您可以看到峰值高達每秒2000個I / O，這表明(至少對于工作負載的某些部分)，數(shù)據(jù)庫工作集與內(nèi)存不匹配。
MySQL優(yōu)化關鍵5：使用SSD存儲
如果您的數(shù)據(jù)庫不適合內(nèi)存，但仍然需要快速存儲來處理寫入，并避免數(shù)據(jù)庫加速(重新啟動之后)時出現(xiàn)性能問題。 這些快速存儲意味著需要使用SSD。
由于成本或可靠性原因，一些“專家”仍然主張使用旋轉(zhuǎn)磁盤。但在操作數(shù)據(jù)庫中，這些觀點往往是過時的或錯誤的。今天，SSD在友好的價格上提供了令人印象深刻的性能和可靠性。
然而，不是所有的SSD都是相同的。對于數(shù)據(jù)庫服務器，您應該使用專為服務器工作負載設計的SSD。
一種直接通過NVMe或Intel Optane技術直接連接的SSD可提供最佳性能。即使作為SAN，NAS或云塊設備進行遠程連接，與旋轉(zhuǎn)磁盤相比，SSD仍然具有優(yōu)異的性能。
MySQL優(yōu)化關鍵6：向外擴展
即使是性能最好的服務器也有局限性。有兩種擴展方式：up和out。up意味著購買更多的硬件，但硬件很貴且很快就會過時。out有幾個好處：
可以利用更小、成本更低的系統(tǒng)。
通過向外擴展能更快更容易的線性放縮。
由于數(shù)據(jù)庫分布在多臺物理機上，因此數(shù)據(jù)庫不會收到單椅硬件故障的影響。
雖然向外擴展有優(yōu)勢，但也有一定的局限性。味了數(shù)據(jù)同步，擴展需要復制，例如基本的MySQL或Percona XtraDB集群復制。
您還需要確保連接到集群架構(gòu)的應用程序可以找到所需的數(shù)據(jù)，通常要通過一些代理服務器和負載平衡器來實現(xiàn)，如ProxySQL或HAProxy。
在計劃擴展的同時，要避免過早的擴張，使用分布式數(shù)據(jù)庫往往更復雜。
MySQL優(yōu)化關鍵7：擁有可觀察性
最好的系統(tǒng)在設計時要考慮到可觀察性。
您將MySQL環(huán)境設置好、運行并正確調(diào)整之后，也不能就將它放置不管，數(shù)據(jù)庫環(huán)境可能受到系統(tǒng)或工作負載更改的影響。為流量達到峰值、應用程序錯誤和MySQL故障等情況做好準備。
當這些情況發(fā)生時，你需要快速有效地解決它們。實現(xiàn)這一點的唯一方法是設置一些監(jiān)控解決方案并進行正確的檢測。這可以讓您看到數(shù)據(jù)庫環(huán)境中正在運行的情況，并在出現(xiàn)問題時分析錯誤。理想情況下，系統(tǒng)能在發(fā)生事件之前進行攔截。
MySQL EntERPrise Monitor，Monyog和Percona監(jiān)控和管理(PMM)都是不錯的監(jiān)控工具，具有免費和開源的優(yōu)勢。這些工具為監(jiān)控和故障排除提供了良好的操作可見性
隨著越來越多的公司轉(zhuǎn)向開源數(shù)據(jù)庫(特別是MySQL)，以此來管理和服務于大規(guī)模生產(chǎn)環(huán)境中的業(yè)務數(shù)據(jù)，他們需要專注于保持這些數(shù)據(jù)庫的調(diào)整和運行的最佳效率。數(shù)據(jù)庫性能可能會導致或破壞您的業(yè)務目標，MySQL為您的應用程序和網(wǎng)站提供優(yōu)質(zhì)的數(shù)據(jù)庫解決方案，但要根據(jù)您的需求進行調(diào)整，以滿足您的需求并進行監(jiān)控、查找、防止瓶頸和性能問題。
轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標題：7大絕招幫你輕輕松松提升MySQL性能
本文網(wǎng)址：http://www.ezxoed.cn/html/support/11121521390.html
相關文章
