所有 MySQL 支持的應用程序都可以從經過微調的數據庫服務器中受益。 多年來，Liquid Web Heroic 支持團隊遇到了許多情況。在那裡，一些小的調整對網站和應用程序的性能產生了很大的影響。本系列文章概述了一些對性能影響最大的常見建議。

預檢

本文適用於大多數基於 Linux 的 MySQL VPS 服務器。這包括但不限於傳統的專用服務器和運行各種流行 Linux 發行版的雲 VPS 服務器。本文適用於以下 Liquid web 系統類型：

  • 核心託管 CentOS 6x / 7x
  • 核心管理的 Ubuntu 14.04 / 16.04
  • 完全託管的 CentOS 6/7 cPanel
  • 完全託管的 CentOS 7 Plesk Onyx 17
  • 自我管理的 Linux 服務器

注意選擇不直接支持的自我管理系統可以利用此處描述的技術，但 LiquidWebHeroic 支持團隊無法直接支持這些服務器類型。

本系列文章假設您熟悉以下基本系統管理概念：

  • SSH 連接和標準基本導航 Linux命令行shell環境..
  • 打開、編輯和保存文件 維姆 或您選擇的系統編輯器。
  • MySQL交互模式 和常見的 MySQL 查詢語法。

什麼是 MySQL 優化？

MySQL 優化這個術語沒有很好的定義。含義可能因個人、管理員、團體或公司而異。 在這個 MySQL 優化系列文章中，我們對 MySQL 優化的定義如下：配置預配置的 MySQL 或 MariaDB 服務器以避免本系列文章中描述的常見瓶頸。

什麼是瓶頸？

與汽水瓶瓶頸類似，技術術語瓶頸是應用程序或服務器配置中允許少量流量或數據順利通過的點。但是，大量相同類型的流量或數據被阻塞或阻塞，無法按原樣正常運行。請參閱以下配置瓶頸示例。

在此示例中，服務器可以處理 10 個並發連接。但是，此配置僅接受 5 個連接。如果一次連接數為 5 個或更少，則不會發生此問題。但是，隨著流量增加到 10 個連接，由於服務器配置中未使用的資源，其中一半開始失敗。上面的例子顯示了瓶頸的形狀。瓶頸的形狀來自它的名字，並帶有一個優化的配置來修復瓶頸。

什麼時候需要優化 MySQL 數據庫？

理想情況下，應在生產力下降之前定期進行數據庫性能調整。最佳實踐是每週或每月審核數據庫性能，以防止問題對您的應用程序產生不利影響。性能問題最明顯的症狀是：

  • 查詢在 MySQL 進程表中累積並且永遠不會完成。
  • 使用數據庫的應用程序或網站會很慢。
  • 連接超時錯誤，尤其是在高峰時段。

在繁忙的系統上同時運行多個查詢是正常的，但是當這些查詢需要很長時間才能定期完成時就會出現問題。確切的閾值取決於您的系統和應用程序，但超過幾秒的平均查詢時間會導致其他網站和應用程序的速度變慢。這些減速開始時很小，並且在大量流量激增達到特定瓶頸之前可能會被忽視。

識別性能問題

要診斷已發生的特定瓶頸，了解如何查看 MySQL 進程表很重要。有幾種查看進度表的方法，具體取決於您的特定服務器和設置。為簡潔起見，在本系列中 安全外殼 (SSH) 訪問：

方法一、使用MySQL進程表

利用’mysql管理員“帶有標誌的命令行工具”進程列表‘ 還’處理‘縮寫。 （添加一個標誌’統計數據‘ 還’狀態‘簡而言之，顯示自上次重啟 MySQL 以來的查詢執行統計信息。 ）。

命令：

mysqladmin proc stat

輸出：

 +-------+------+-----------+-----------+---------+------+-------+
 | Id    | User | Host      | db        | Command | Time | State | Info               | Progress |
 +-------+------+-----------+-----------+---------+------+-------+--------------------+----------+
 | 77255 | root | localhost | employees | Query   | 150  |       | call While_Loop2() | 0.000    |
 | 77285 | root | localhost |           | Query   | 0    | init  | show processlist   | 0.000    |
 +-------+------+-----------+-----------+---------+------+-------+--------------------+----------+
 Uptime: 861755  Threads: 2  Questions: 20961045  Slow queries: 0  Opens: 2976  Flush tables: 1  Open tables: 1011  Queries per second avg: 24.323

筆記：親愛的： 在 shell 界面中使用，您可以輕鬆地將輸出通過管道傳輸到其他腳本和工具。什麼時候： 進程表中的信息列總是被截斷，所以對於長查詢不提供完整的查詢

方法二：使用MySQL進程表

我越界了。”顯示進程列表。‘從 MySQL 交互模式提示中查詢。 （添加’滿的‘命令限定符禁用截斷 信息 支柱。這在顯示長查詢時是必要的。 )。

命令：

show processlist;

輸出：

MariaDB [(none)]> show full processlist;
 +-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+
 | Id    | User | Host      | db        | Command | Time | State | Info                  | Progress |
 +-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+
 | 77006 | root | localhost | employees | Query   |  151 | NULL  | call While_Loop2()    |    0.000 |
 | 77021 | root | localhost | NULL      | Query   |    0 | init  | show full processlist |    0.000 |
 +-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+

親愛的： 使用完整限定符查看更長查詢的完整查詢。什麼時候： 在 MySQL 交互模式下，您無法訪問 shell 界面中可用的腳本和工具。..

使用慢查詢日誌

MySQL 中另一個有價值的工具是包含的慢查詢日誌記錄功能。此功能是定期搜索長時間運行查詢的推薦方法。您可以使用幾個指令來調整此功能。但是，最常見的設置是：

見表

慢查詢日誌啟用/禁用慢查詢日誌
慢查詢日誌文件慢查詢日誌文件名和路徑
long_query_time定義慢查詢的時間（秒/微秒）

這些步驟設置在 [mysqld] MySQL 配置文件部分位於： /etc/my.cnf 您還需要重新啟動 MySQL 服務才能生效。有關格式，請參見下面的示例。

警告：慢查詢日誌文件存在磁盤空間過大問題，在禁用慢查詢日誌功能之前，請繼續注意。 請記住，long_query_time 指令越低，慢查詢日誌將填滿磁盤分區的速度越快。

[mysqld]
 log-error=/var/lib/mysql/mysql.err
 innodb_file_per_table=1
 default-storage-engine=innodb
 innodb_buffer_pool_size=128M
 innodb_log_file_size=128M
 max_connections=300
 key_buffer_size = 8M
 slow_query_log=1
 slow_query_log_file=/var/lib/mysql/slowquery.log
 long_query_time=5

當您啟用慢查詢日誌記錄時，您需要定期跟進以查看需要調整以提高性能的不規則查詢。要分析慢查詢日誌文件，請直接分析該文件以查看其內容。以下示例顯示運行時間超過配置的 5 秒的示例查詢的統計信息。

溫暖的啟用慢查詢日誌記錄功能會降低性能。這是由於分析每個查詢所需的額外例程以及將所需查詢寫入日誌文件所需的 I/O。因此，在生產系統上禁用慢查詢日誌記錄被認為是最佳實踐。如果您正在積極尋找可能影響您的應用程序或網站的討厭查詢，則應僅在特定時間段內啟用慢查詢日誌。

# Time: 180717  0:23:28
 # [email protected]: root[root] @ localhost []
 # Thread_id: 32  Schema: employees  QC_hit: No
 # Query_time: 627.163085  Lock_time: 0.000021  Rows_sent: 0  Rows_examined: 0
 # Rows_affected: 0
 use employees;
 SET timestamp=1531801408;
 call While_Loop2();

或者，您可以使用 mysqldumpslow 命令行工具。該工具解析慢查詢日誌文件並將類似查詢分​​組，但數值和字符串數據的值除外。

~ $ mysqldumpslow -a /var/lib/mysql/slowquery.log
 Reading mysql slow query log from /var/lib/mysql/slowquery.log
 Count: 2  Time=316.67s (633s)  Lock=0.00s (0s)  Rows_sent=0.5 (1), Rows_examined=0.0 (0), Rows_affected=0.0 (0), root[root]@localhost
 call While_Loop2()

（訪問這個 MySQL 文檔以了解使用 – mysqldumpslow — 總結慢查詢日誌文件)。

您需要了解的有關高可用性的所有信息

結論是

這結束了數據庫優化系列的第一部分，並為基準測試提供了堅實的基礎。數據庫問題可能很複雜，但本系列將分解這些概念，並提供通過數據庫轉換、表轉換和索引來優化數據庫的方法。

我們能幫你什麼嗎？

我們很自豪能成為 Hosting™ 最有用的人！

我們的支持團隊由經驗豐富的 Linux 工程師和才華橫溢的系統管理員組成，他們對許多網絡託管技術有深入的了解，尤其是本文中描述的技術。

如果您對此信息有任何疑問，我們將很樂意每週 7 天、每天 24 小時回答與本文相關的任何問題。

如果您是完全託管的 VPS 服務器、雲專用服務器、VMWare 私有云、私有父服務器、託管雲服務器或專用服務器的所有者，並且不確定執行任何列出的步驟，請致電 @ 請致電 800.580 聯繫我們。 4985，一個 聊天 或支持票以協助此過程。

By Archives, News