共計 4157 個字符，預計需要花費 11 分鐘才能閱讀完成。
本篇內容主要講解“mysql 慢查詢如何優化”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓丸趣 TV 小編來帶大家學習“mysql 慢查詢如何優化”吧!
1 慢查詢優化思路
當發生慢查詢的時候，優化的思路為：
利用慢查詢日志定位慢查詢 SQL
通過 explain 分析慢查詢 SQL
修改 SQL，盡量讓 SQL 走索引
2 慢查詢日志
MySQL 提供了一個功能——慢查詢日志，會記錄查詢時間超過指定時間閾值的 SQL 到日志中，便于我們定位慢查詢并且優化對應的 SQL 語句。
首先查看 MySQL 中關于慢查詢相關的全局變量：
mysql show global variables like %quer%
+----------------------------------------+-------------------------------+
| Variable_name | Value |
+----------------------------------------+-------------------------------+
| binlog_rows_query_log_events | OFF |
| ft_query_expansion_limit | 20 |
| have_query_cache | YES |
| log_queries_not_using_indexes | OFF |
| log_throttle_queries_not_using_indexes | 0 |
==========================================================================
| long_query_time | 10.000000 |【1】慢查詢的時間閾值
==========================================================================
| query_alloc_block_size | 8192 |
| query_cache_limit | 1048576 |
| query_cache_min_res_unit | 4096 |
| query_cache_size | 16777216 |
| query_cache_type | OFF |
| query_cache_wlock_invalidate | OFF |
| query_prealloc_size | 8192 |
==========================================================================
| slow_query_log | OFF |【2】慢查詢日志是否開啟
| slow_query_log_file | /var/lib/mysql/Linux-slow.log |【3】慢查詢日志文件存儲位置
==========================================================================
+----------------------------------------+-------------------------------+
15 rows in set (0.00 sec)這里主要關注三個變量：
long_query_time，慢查詢的時間閾值，單位秒，如果一個 SQL 語句的執行時間超過這個值，那么 MySQL 就認定其為慢查詢
slow_query_log，慢查詢日志功能是否開啟，默認關閉，開啟后記錄慢查詢
slow_query_log_file，慢查詢日志文件的存儲位置
默認慢查詢日志功能是關閉的，因此我們需要啟動該功能
# 開啟慢查詢日志
mysql set global slow_query_log=ON;
Query OK, 0 rows affected (0.00 sec)
# 設置慢查詢時間閾值
mysql set long_query_time=1;
Query OK, 0 rows affected (0.00 sec)這樣子設置后，MySQL 重啟會丟失這些配置，需要在配置文件中修改才會永久有效。
3 explain
我們可以使用 explain 分析 SQL 語句的執行情況，例如：
mysql explain select sum(1+2);執行結果如下，可以看到有很多字段
我們主要看看一些重要的字段：
select_type 表示查詢語句的查詢類型，包括簡單查詢、子查詢等等
table 表示查詢的表，不一定是存在表，可能是本次查詢中得到的臨時表
type 表示檢索類型，使用全表掃描、還是索引掃描等
possible_keys 表示可能使用的索引列
keys 表示查詢中實際使用的索引列，由查詢優化器決定
3.1 select_type 字段
3.2 type 字段
對于 InnoDB 存儲引擎，type 列通常都是 all 或者 index。
關于 type 字段的值，其從上到下對應的 SQL 的執行性能逐漸變差。
3.3 extra 字段
4 慢查詢例子
準備數據，數據表結構：
create table user_info_large (
`id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 主鍵 ,
`account` VARCHAR(20) NOT NULL COMMENT 用戶賬號 ,
`name` VARCHAR(20) NOT NULL COMMENT 用戶名 ,
`password` VARCHAR(20) not null COMMENT 用戶密碼 ,
`area` VARCHAR(20) NOT NULL COMMENT 用戶地址 ,
`signature` VARCHAR(50) not null COMMENT 個性簽名 ,
PRIMARY KEY (`id`) COMMENT 主鍵 ,
UNIQUE (`account`) COMMENT 唯一索引 ,
KEY `index_area_signture` (`area`, `signature`) COMMENT 組合索引
);隨機生成 200w 條數據
mysql select count(id) from user_info_large;
+-----------+
| count(id) |
+-----------+
| 2000000 |
+-----------+
1 row in set (0.38 sec)截取部分數據：
執行以下 SQL 語句，沒有使用任何索引字段：
SELECT name from user_info_large ORDER BY name desc limit 0,100000;Navicat 工具顯示的查詢時間如下，這并不是 MySQL 真正執行 SQL 的時間，這里面包含了網絡傳輸等時間：
SQL 具體的查詢時間可以查看慢查詢日志：
# Time: 2022-09-26T13:44:18.405459Z
# User@Host: root[root] @ [ip] Id: 1893
# Query_time: 10.162999 Lock_time: 0.000113 Rows_sent: 100000 Rows_examined: 2100000
SET timestamp=1664199858;
SELECT name from user_info_large ORDER BY name desc limit 0,100000;
關于其中一些信息的說明：
Time：SQL 執行的開始時間
Query_time：SQL 語句查詢花費的時間，可以看到花費了 10 秒鐘
Lock_time：等待鎖表的時間
Rows_sent：語句返回的記錄數
Rows_examined：從存儲引擎中返回的記錄數
正在執行的慢查詢是不會被記錄到慢查詢日志的，只有等待其執行完畢才會記錄到日志中。
我們可以使用 show processlist 查看正在執行 SQL 的線程。
再執行以下語句，使用索引 account 字段：
SELECT account from user_info_large ORDER BY account desc limit 0,100000;查看慢查詢日志，并沒有被記錄下來。
現在分別使用 explain 查看 SQL 語句的執行情況：
explain SELECT name from user_info_large ORDER BY name desc limit 0,100000;
分析情況如下：
可以看到沒有使用到索引，type 為 ALL 表示全表掃描，效率最差，并且 Extra 也是外部排序。
再看看這條 SQL 語句：
explain SELECT account from user_info_large ORDER BY account desc limit 0,100000;
分析情況如下：
type 為 index，使用了索引，使用的索引字段為 account，Extra 顯示為使用索引排序。
因此，在實際開發中，我們可以針對慢查詢的 SQL，使用 explain 分析語句，根據分析情況以及索引的設計，重新設計 SQL 語句，讓 SQL 語句盡量走索引，走合適的索引。
5 優化器與索引
在執行 SQL 時，MySQL 的優化器會根據情況選擇索引，但并不能保證其執行時間一定最短，我們可以根據實際情況使用 force key (index) 讓 SQL 語句強制走某個索引。
例如，以下語句執行后，key 字段為 account，并沒有走主鍵索引。
explain SELECT count(id) from user_info_large;如果使用 force key，就可以強制令語句走主鍵索引。
explain SELECT count(id) from user_info_large force key (PRIMARY);到此，相信大家對“mysql 慢查詢如何優化”有了更深的了解，不妨來實際操作一番吧！這里是丸趣 TV 網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
