共計 4292 個字符，預計需要花費 11 分鐘才能閱讀完成。
這篇文章給大家分享的是有關怎么用 status 信息對 MySQL 服務器進行優化的內容。丸趣 TV 小編覺得挺實用的，因此分享給大家做個參考，一起跟隨丸趣 TV 小編過來看看吧。
網上有很多的文章教怎么配置 MySQL 服務器，但考慮到服務器硬件配置的不同，具體應用的差別，那些文章的做法只能作為初步設置參考，我們需要根據自己的情況進行配置優化，好的做法是 MySQL 服務器穩定運行了一段時間后運行，根據服務器的”狀態”進行優化。
show global status;
可以列出 MySQL 服務器運行各種狀態值，另外，查詢 MySQL 服務器配置信息語句：
mysql show variables;
一、慢查詢
mysql show variables like %slow%;
+——————+——-+
| Variable_name | Value |
+——————+——-+
| log_slow_queries | ON |
| slow_launch_time | 2 |
+——————+——-+
mysql show global status like %slow%;
+———————+——-+
| Variable_name | Value |
+———————+——-+
| Slow_launch_threads | 0 |
| Slow_queries | 4148 |
+———————+——-+
配置中打開了記錄慢查詢，執行時間超過 2 秒的即為慢查詢，系統顯示有 4148 個慢查詢，你可以分析慢查詢日志，找出有問題的 SQL 語句，慢查詢時間不宜設置過長，否則意義不大，最好在 5 秒以內，如果你需要微秒級別的慢查詢，可以考慮給 MySQL 打補?。?，記得找對應的版本。
打開慢查詢日志可能會對系統性能有一點點影響，如果你的 MySQL 是主-從結構，可以考慮打開其中一臺從服務器的慢查詢日志，這樣既可以監控慢查詢，對系統性能影響又小。
二、連接數
經常會遇見”MySQL: ERROR 1040: Too many connections”的情況，一種是訪問量確實很高，MySQL 服務器抗不住，這個時候就要考慮增加從服務器分散讀壓力，另外一種情況是 MySQL 配置文件中 max_connections 值過?。?/p>
mysql show variables like max_connections;
+—————–+——-+
| Variable_name | Value |
+—————–+——-+
| max_connections | 256 |
+—————–+——-+
這臺 MySQL 服務器最大連接數是 256，然后查詢一下服務器響應的最大連接數：
mysql show global status like Max_used_connections;
+———————-+——-+
| Variable_name | Value |
+———————-+——-+
| Max_used_connections | 245 |
+———————-+——-+
MySQL 服務器過去的最大連接數是 245，沒有達到服務器連接數上限 256，應該沒有出現 1040 錯誤，比較理想的設置是：
Max_used_connections / max_connections * 100% ≈ 85%
最大連接數占上限連接數的 85%左右，如果發現比例在 10% 以下，MySQL 服務器連接數上限設置的過高了。
三、Key_buffer_size
key_buffer_size 是對 MyISAM 表性能影響最大的一個參數，下面一臺以 MyISAM 為主要存儲引擎服務器的配置：
mysql show variables like key_buffer_size;
+—————–+————+
| Variable_name | Value |
+—————–+————+
| key_buffer_size | 536870912 |
+—————–+————+
分配了 512MB 內存給 key_buffer_size，我們再看一下 key_buffer_size 的使用情況：
mysql show global status like key_read%;
+————————+————-+
| Variable_name | Value |
+————————+————-+
| Key_read_requests | 27813678764 |
| Key_reads | 6798830 |
+————————+————-+
一共有 27813678764 個索引讀取請求，有 6798830 個請求在內存中沒有找到直接從硬盤讀取索引，計算索引未命中緩存的概率：
key_cache_miss_rate = Key_reads / Key_read_requests * 100%
比如上面的數據，key_cache_miss_rate 為 0.0244%，4000 個索引讀取請求才有一個直接讀硬盤，已經很 BT 了，key_cache_miss_rate 在 0.1% 以下都很好（每 1000 個請求有一個直接讀硬盤），如果 key_cache_miss_rate 在 0.01% 以下的話，key_buffer_size 分配的過多，可以適當減少。
MySQL 服務器還提供了 key_blocks_* 參數：
mysql show global status like key_blocks_u%;
+————————+————-+
| Variable_name | Value |
+————————+————-+
| Key_blocks_unused | 0 |
| Key_blocks_used | 413543 |
+————————+————-+
Key_blocks_unused 表示未使用的緩存簇 (blocks) 數，Key_blocks_used 表示曾經用到的最大的 blocks 數，比如這臺服務器，所有的緩存都用到了，要么增加 key_buffer_size，要么就是過渡索引了，把緩存占滿了。比較理想的設置：
Key_blocks_used / (Key_blocks_unused + Key_blocks_used) * 100% ≈ 80%
四、臨時表
mysql show global status like created_tmp%;
+————————-+———+
| Variable_name | Value |
+————————-+———+
| Created_tmp_disk_tables | 21197 |
| Created_tmp_files | 58 |
| Created_tmp_tables | 1771587 |
+————————-+———+
每次創建臨時表，Created_tmp_tables 增加，如果是在磁盤上創建臨時表，Created_tmp_disk_tables 也增加,Created_tmp_files 表示 MySQL 服務創建的臨時文件文件數，比較理想的配置是：
Created_tmp_disk_tables / Created_tmp_tables * 100% = 25%
比如上面的服務器 Created_tmp_disk_tables / Created_tmp_tables * 100% = 1.20%，應該相當好了。我們再看一下 MySQL 服務器對臨時表的配置：
mysql show variables where Variable_name in (tmp_table_size, max_heap_table_size);
+———————+———–+
| Variable_name | Value |
+———————+———–+
| max_heap_table_size | 268435456 |
| tmp_table_size | 536870912 |
+———————+———–+
只有 256MB 以下的臨時表才能全部放內存，超過的就會用到硬盤臨時表。
五、Open Table 情況
mysql show global status like open%tables%;
+—————+——-+
| Variable_name | Value |
+—————+——-+
| Open_tables | 919 |
| Opened_tables | 1951 |
+—————+——-+
Open_tables 表示打開表的數量，Opened_tables 表示打開過的表數量，如果 Opened_tables 數量過大，說明配置中 table_cache(5.1.3 之后這個值叫做 table_open_cache)值可能太小，我們查詢一下服務器 table_cache 值：
mysql show variables like table_cache;
+—————+——-+
| Variable_name | Value |
+—————+——-+
| table_cache | 2048 |
+—————+——-+
比較合適的值為：
Open_tables / Opened_tables * 100% = 85%
Open_tables / table_cache * 100% = 95%
感謝各位的閱讀！關于“怎么用 status 信息對 MySQL 服務器進行優化”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！
