搜尋“提升 VPS 資料庫效能”,你會發現很多主機公司都在部落格文章中推銷 VPS 升級方案。
但單靠升級並不能解決你的問題。
你只會在更昂貴的伺服器上執行緩慢的資料庫。事實上,大多數網站並不需要升級,尤其不需要將其作為提升效能的第一步。
在考慮升級之前,你需要最佳化網站和資料庫。
這就是我們編寫本指南的目的——幫助你最佳化現有 VPS 的資料庫效能。
“最佳化資料庫效能”是什麼意思?
最佳化資料庫效能意味著系統地提高資料庫處理查詢、處理併發使用者和管理資源的速度和效率。這涉及索引、查詢最佳化和硬體調優等技術,以縮短響應時間、提高吞吐量並降低運營成本,同時保持資料準確性和系統可靠性。
具體操作如下:
把你的資料庫想象成一個儲藏室。隨著時間的推移,東西會越積越多,直到沒有空間移動,找到你需要的東西也需要很長時間。
為了解決這個問題,你可以:
- 購買更大的儲存空間。
- 移除不必要的物品。
更好的選擇:先移除不必要的物品。將雜物移到更大的空間並不能解決根本問題。幾個月後,你可能會遇到同樣的問題,儘管現在你的儲存空間更大了。
你的資料庫也是這樣運作的。它會收集資料(甚至會囤積你不再需要的東西),所以你需要定期清理。
真的是資料庫或網站程式碼臃腫了嗎?
您需要檢查究竟是什麼拖慢了您的網站速度。
當資料庫成為瓶頸時:
- 包含動態內容(例如產品列表或部落格存檔)的頁面載入緩慢。
- 管理文章或產品時,您的網站管理區域感覺遲鈍。
- 資料庫查詢需要超過 1-2 秒才能完成。
- 高峰流量時段會導致速度明顯下降。
當網站程式碼成為問題時:
- 即使資料庫活動很少,您的網站載入也需要很長時間。(即使是靜態頁面載入也很慢!)
- 大型影像檔案或未最佳化的媒體檔案會拖慢載入時間(請先檢查 GTmetrix)。
- 過多的外掛或繁重的主題會導致延遲。
快速診斷工具:
- 使用 Query Monitor (適用於 WordPress)等工具檢視哪些資料庫查詢耗時最長。
- 在高峰時段檢查伺服器的 CPU 和記憶體使用情況。
- 對資料庫密集型頁面和靜態頁面執行 PageSpeed 測試,比較載入時間。
如果資料庫查詢持續超過幾秒鐘,或者資料庫密集型頁面的載入速度明顯慢於靜態頁面,則表明存在需要解決的資料庫效能問題。
如何最佳化VPS上的資料庫效能?
以下是讓您的資料庫像使用效能增強外掛一樣執行的分步指南:
1. 更新您的VPS軟體
這聽起來很簡單,但許多網站所有者在網站上線後從未更新過他們的 VPS 作業系統或伺服器軟體。
重要性:過時的資料庫軟體最容易導致您錯過開發人員釋出的效能改進和安全補丁。
例如,資料庫效能測試顯示,較新版本的 MariaDB 比同期的 MySQL 版本快 13%-36%。因此,如果您仍在使用較舊的資料庫版本,更新到最新版本應該會顯著提升效能。
具體更新內容:
- 資料庫軟體:MySQL 或 MariaDB
- PHP 版本:PHP 8.4(最新穩定版本,釋出於 2024 年 11 月)或 PHP 8.3,以實現最大相容性
- 作業系統:請使用最新的安全補丁更新您的 Linux 發行版
- Web 伺服器:Apache 或 NGINX
提示:請務必先在測試環境中測試更新!您肯定不希望您的線上網站因為相容性問題而崩潰。
2. 清理資料庫臃腫
還記得那個儲藏室的比喻嗎?現在是時候整理一下你的資料庫了。
以下是一些你需要定期清理的常見資料庫雜亂:
- 舊帖子修訂(WordPress 每篇帖子最多可儲存 50 多個修訂版本)
- 垃圾評論和未使用的評論後設資料
- 過期的臨時檔案和快取資料
- 未使用的外掛剩餘表
- 幾個月未清理的日誌檔案
對於 WordPress 使用者:
- 使用外掛,例如 WP-Optimize 或 Advanced Database Cleaner。
透過在 wp-config.php 檔案中新增Define ('WP_POST_REVISIONS', 3);
來限制文章修訂次數。
定期清理垃圾評論。
將你的 PHP 版本升級到 PHP 8.4,其中包含效能改進,包括 2 到 5 倍的 SHA-256 運算速度和最佳化的 Sprint 函式。
對於其他平臺:
- 對頻繁更新的表執行 OPTIMIZE TABLE 命令。
- 刪除超過 30 天的不必要的日誌條目。
- 刪除您在開發期間建立的測試資料或虛擬資料。
3. 資料庫索引
可以將資料庫索引想象成一本書的目錄。
如果沒有索引,您的資料庫必須掃描每一行才能找到所需內容。有了索引,資料庫就可以快速找到您請求的資料。正確的索引可以將查詢時間從幾秒縮短到幾毫秒,並有助於顯著提高資料庫效能,尤其是在資料庫規模較大的情況下。
對於 WordPress,可以使用 Index WP MySQL For Speed 之類的外掛,按照外掛中的步驟操作即可。
但是,在索引資料庫之前,您絕對需要建立網站備份。
何時新增索引:
- 您擁有包含數千行產品、部落格文章、使用者等資料的大型表
- 您經常搜尋或篩選的列
- 外部索引鍵列
- “JOIN”操作或“WHERE”子句中使用的許多列
何時不新增索引:
- 小型表(少於 1,000 行通常不會帶來任何效能提升)
- 頻繁更改的列(索引會減慢“INSERT/UPDATE”操作的速度)
- 您空間不足,希望充分利用資源(索引會佔用空間)
4. 設定查詢快取
您的資料庫就像一位樂於助人的圖書管理員,經常被要求借閱同一套(熱門)書籍。聰明的圖書管理員不會走到後屋,一遍又一遍地尋找書籍,而是會記住書籍的位置,甚至可能將它們放在辦公桌抽屜裡。
查詢快取與此類似。當您的資料庫執行查詢時,它會將結果儲存在記憶體中。下次有人請求相同的資料時,您的資料庫無需再次執行復雜的查詢,而是幾乎立即提供快取的結果。
如果資料更新,快取的結果也會更新,新使用者將自動獲得最新的結果。
以下是為 MySQL 8.0 使用者(最常見)實現查詢快取的方法:
- ProxySQL:MySQL 查詢快取的推薦替代品。它位於應用程式和資料庫之間,透過可配置的TTL快取結果。
- 應用程式級快取:WordPress使用者應使用 W3 Total Cache 等快取外掛,而不是資料庫級快取,以便更快地實現。
- Redis或Memcached:外部快取系統,需要更改程式碼,但提供更好的控制力和可擴充套件性。一些託管產品為電商網站、會員網站以及新聞或部落格網站提供內建的 Redis 物件快取。
對於大多數小型網站,您可以完全安全地跳過資料庫級查詢快取。相反,請先使用CMS或應用程式的內建快取功能。如果您需要更高的效能,請聯絡開發人員實現用於物件快取的Redis例項。
重要更新:MySQL 的內建查詢快取在 MySQL 5.7.20 中已棄用,並在MySQL 8.0中完全刪除。雖然 MariaDB 仍然支援查詢快取,但由於多核機器上的可擴充套件性問題,它預設是停用的。
5. 調整資料庫配置
您的資料庫預設設定適用於任何伺服器,從小型共享主機到企業級硬體。但就像一件千篇一律的T恤一樣,這些設定並非根據您的需求進行最佳化,只是完成工作而已。
VPS 環境允許您根據具體配置自定義這些設定。
以下是針對 MySQL 和 MariaDB 資料庫最顯著的變化:
innodb_buffer_pool_size
:設定為可用記憶體的 70-80%。對於 4GB 的 VPS,使用大約 3GB 的記憶體。innodb_redo_log_capacity
:對於 MySQL 8.0.30 及更高版本,初始設定為 1-2GB(替換舊的 innodb_log_file_size 設定)。max_connections
:設定為 CPU 核心數的 4 倍,最低設定為 100 個。大多數小型網站只需要 20-50 個。query_cache_size
:MySQL 5.7/MariaDB 為 128M-256M(MySQL 8.0 已完全移除查詢快取)。
使用 MySQL Tuner 或 PGTune 可根據您的實際使用模式獲得個性化建議。這些工具會分析您當前的設定並建議最佳值。
專業提示:MySQL 8.0.30 及更高版本允許您在不重啟的情況下調整重做日誌的大小:
SET GLOBAL innodb_redo_log_capacity = 2147483648
更改配置前,請務必備份資料庫!請先在預釋出環境進行測試,然後在低流量時段進行測試。
6. 選擇合適的儲存引擎
將儲存引擎視為不同的資料歸檔系統。您需要以不同的方式組織資料以適應所使用的儲存引擎。
大多數現代應用程式使用 InnoDB(MySQL 的預設引擎),但在某些情況下,VPS 上也需要使用其他引擎。
- InnoDB(推薦用於大多數網站):非常適合電商網站、部落格和頻繁更新的應用程式。它支援事務、外部索引鍵和崩潰恢復。缺點是記憶體佔用略高,但在擁有專用資源的 VPS 上,這通常不是問題。
- MyISAM(謹慎使用):讀取密集型操作速度更快,佔用記憶體更少,但缺乏崩潰恢復和事務支援。僅對很少更改的表(例如查詢表或存檔)才考慮使用 MyISAM。
- 記憶體(僅限特殊情況):將資料儲存在 RAM 中以實現閃電般的訪問速度,但在伺服器重啟時會丟失所有資料。它非常適合在您控制環境的 VPS 上儲存臨時資料或會話。
要檢查表使用的儲存引擎,請執行:
SHOW TABLE STATUS;
在 MySQL 控制檯中,您可以使用以下命令轉換表:
ALTER TABLE your_table ENGINE = InnoDB;
VPS 的優勢:與共享主機不同,您可以完全控制儲存引擎的選擇,並且可以選擇同時執行多個引擎而不受限制。當然,這意味著您必須在一開始就謹慎選擇,以避免以後出現遷移問題。
7. 持續監控和測試
資料庫最佳化並非“設定後就忘了”的任務。您的網站規模會不斷擴大,流量模式也會發生變化,上個月有效的方法今天可能就不再適用了。
好訊息是,VPS 環境讓監控變得簡單,因為您可以完全訪問系統資源和資料庫日誌。
以下是一些必備的監控工具:
- htop 或 top:即時監控 CPU 和記憶體使用情況。
- iostat 命令:檢查磁碟 I/O 效能(安裝方法:
apt-get install sysstat
)。 - MySQL 程序列表:執行 SHOW PROCESSLIST; 以檢視活躍查詢。
- 慢查詢日誌:啟用此功能可以捕獲耗時超過 2 秒的查詢。
您可以使用 GTmetrix 或 Google PageSpeed Insights 等工具設定每週檢查,重點關注那些佔用大量資料庫的頁面,例如產品頁面、搜尋結果或部落格存檔。
尤其要關注您的首次位元組時間 (TTFB),因為這通常是資料庫效能問題容易被發現的地方。在上面的螢幕截圖中,您可以看到 TTFB 為 0.7 秒。
縮短 TTFB 時間還可以提高您的 Core Web Vitals 得分,這是 Google 的排名指標之一。
需要注意的危險訊號:
- TTFB 持續超過 1 秒
- 正常流量下記憶體使用率超過 80%
- 慢查詢日誌重複顯示相同的查詢
- 資料庫連線在高峰時段達到最大值
當您發現問題時,不要驚慌,也不要立即認為您需要升級 VPS。通常,我們介紹的某項最佳化只需要進行一些微調。
何時應該真正升級VPS?
在我們之前的儲藏室比喻中,你一定記得我們為了適應同一個房間而進行了最佳化(清理了垃圾)。
但是,如果即使在最佳化之後空間仍然不足,那麼你的房間已經不夠用了,是時候購買更大的 VPS 了。
VPS 升級也是如此。如果你已經完成了所有最佳化,但效能仍然沒有太大變化,那麼你可能需要升級到更大的 VPS。
以下幾個明顯的訊號可以告訴你 VPS 是否是瓶頸:
- 在正常流量下,CPU 使用率持續超過 80%。
- RAM 使用率經常超過 85%。
- 資料庫查詢已最佳化,但由於硬體限制,仍然很慢。
- 最佳化後,網站載入時間仍然超過 3 秒。
應該優先升級哪些:
- RAM:通常,對於資料庫密集型網站來說,RAM 是效能提升最大的因素。
- CPU:如果你正在進行大量複雜的計算或處理。
- 儲存:如果您仍在使用傳統 HDD,請升級到 NVMe SSD。
請記住,所有網站的推薦頁面載入時間均應低於 3 秒。儘量縮短載入時間,這樣就沒問題了!
小結
現在,我有一些好訊息和一些不太好的訊息。
好訊息是,您的 VPS 上有一個經過全面最佳化的資料庫,它高效執行,並以閃電般的速度為您的網站提供服務。
不太好的訊息是,這還沒有結束。就像任何其他維護任務一樣,資料庫需要定期最佳化。
但您不再是盲目操作。您知道要查詢什麼以及如何修復它。
如果您使用 WordPress,有許多工具(例如 WP Optimize 和 LiteSpeed Cache 的資料庫最佳化)可以幫助您只需點選幾下即可執行大多數資料庫維護任務。
如果升級是唯一的選擇,請嘗試專業 VPS 套餐,透過高質量的硬體可帶來的網站幾乎瞬間的速度提升。
評論留言