小伙伴想精準查找自己想看的MySQL文章？喏 → MySQL江湖路 | 專欄目錄

??一條慢查詢會造成什么后果？年輕時，我一直覺得不就是回傳資料會慢一些么，用戶體驗變差？其實遠遠不止，我經歷過幾次線上事故，有一次就是由一條SQL慢查詢導致的，

在這里插入圖片描述

??記得那是一條查詢SQL，資料量萬級時還保持在0.2秒內，隨著某一段時間資料猛增，耗時一度達到了2-3秒！沒有命中索引，導致全表掃描，explain 中extra顯示：Using where; Using temporary; Using filesort，被迫使用了臨時表排序，由于是高頻查詢，并發一起來很快就把DB執行緒池打滿了，導致大量查詢請求堆積，DB服務器cpu長時間100%+，大量請求timeout，，最終系統崩潰，老板登場~

??對了，那次是十月二日晚上8點半，我在老家棗莊，和哥兒幾個正坐在大排檔吹著牛B！你猜，我將面臨什么尷尬局面？
在這里插入圖片描述

??可見，團隊如果對慢查詢不引起足夠的重視，風險是很大的，經過那次事故我們老板就說了：誰的代碼再出現類似事故，開發和部門領導一起走人，嚇得一大堆領導心發慌，趕緊招了兩位DBA同事🙂🙂🙂，

在這里插入圖片描述

??慢查詢，顧名思義，執行很慢的查詢，有多慢？超過 long_query_time 引數設定的時間閾值（默認10s），就被認為是慢的，是需要優化的，慢查詢被記錄在慢查詢日志里，

??慢查詢日志默認是不開啟的，如果你需要優化SQL陳述句，就可以開啟這個功能，它可以讓你很容易地知道哪些陳述句是需要優化的（想想一個SQL要10s就可怕），

墨菲定律：會出錯的事情就一定會出錯，

??這是太真實的事情之一了，為了防患于未然，一起來看看慢查詢該怎么處理，本文很干，記得接杯水，沒時間看的先收藏哦！

一、慢查詢配置
- 1-1、開啟慢查詢
- - 方式一：通過命令開啟慢查詢
  - 方式二：通過配置my.cnf（windows是my.ini）系統檔案開啟
- 1-2、慢查詢日志介紹
二、Explain分析慢查詢SQL
- 2-1、各列屬性的簡介：
- 2-2、慢查詢分析常用到的屬性
- - 1、type：
  - 2、key
  - 3、rows
  - 4、Extra
三、一些慢查詢優化經驗分享
- 3-1、優化LIMIT分頁
- - 思路一：構造覆寫索引
  - 思路二：優化offset
  - 方法三：“延遲關聯”
- 3-2、排查索引沒起作用的情況
總結

一、慢查詢配置

1-1、開啟慢查詢

MySQL支持通過

1、輸入命令開啟慢查詢（臨時），在MySQL服務重啟后會自動關閉；
2、配置my.cnf（windows是my.ini）系統檔案開啟，修改組態檔是持久化開啟慢查詢的方式，

方式一：通過命令開啟慢查詢

步驟1、查詢 slow_query_log 查看是否已開啟慢查詢日志：

show variables like '%slow_query_log%';

mysql> show variables like '%slow_query_log%';
+---------------------+-----------------------------------+
| Variable_name       | Value                             |
+---------------------+-----------------------------------+
| slow_query_log      | OFF                               |
| slow_query_log_file | /var/lib/mysql/localhost-slow.log |
+---------------------+-----------------------------------+
2 rows in set (0.01 sec)

步驟2、開啟慢查詢命令：

set global slow_query_log='ON';

步驟3、指定記錄慢查詢日志SQL執行時間得閾值（long_query_time 單位：秒，默認10秒）

如下我設定成了1秒，執行時間超過1秒的SQL將記錄到慢查詢日志中

set global long_query_time=1;

步驟4、查詢 “慢查詢日志檔案存放位置”

show variables like '%slow_query_log_file%';

mysql> show variables like '%slow_query_log_file%';
+---------------------+-----------------------------------+
| Variable_name       | Value                             |
+---------------------+-----------------------------------+
| slow_query_log_file | /var/lib/mysql/localhost-slow.log |
+---------------------+-----------------------------------+
1 row in set (0.01 sec)

slow_query_log_file 指定慢查詢日志的存盤路徑及檔案（默認和資料檔案放一起）

步驟5、核對慢查詢開啟狀態

需要退出當前MySQL終端，重新登錄即可重繪；

配置了慢查詢后，它會記錄以下符合條件的SQL：

查詢陳述句
資料修改陳述句
已經回滾的SQL

方式二：通過配置my.cnf（windows是my.ini）系統檔案開啟

（版本：MySQL5.5及以上）

在my.cnf檔案的[mysqld]下增加如下配置開啟慢查詢，如下圖

# 開啟慢查詢功能
slow_query_log=ON
# 指定記錄慢查詢日志SQL執行時間得閾值
long_query_time=1
# 選填，默認資料檔案路徑
# slow_query_log_file=/var/lib/mysql/localhost-slow.log

在這里插入圖片描述
重啟資料庫后即持久化開啟慢查詢，查詢驗證如下：

mysql> show variables like '%_query_%';
+------------------------------+-----------------------------------+
| Variable_name                | Value                             |
+------------------------------+-----------------------------------+
| have_query_cache             | YES                               |
| long_query_time              | 1.000000                          |
| slow_query_log               | ON                                |
| slow_query_log_file          | /var/lib/mysql/localhost-slow.log |
+------------------------------+-----------------------------------+
6 rows in set (0.01 sec)

1-2、慢查詢日志介紹

在這里插入圖片描述

如上圖，是執行時間超過1秒的SQL陳述句（測驗）

第一行：記錄時間
第二行：用戶名、用戶的IP資訊、執行緒ID號
第三行：執行花費的時間【單位：秒】、執行獲得鎖的時間、獲得的結果行數、掃描的資料行數
第四行：這SQL執行的時間戳
第五行：具體的SQL陳述句

二、Explain分析慢查詢SQL

??分析mysql慢查詢日志 ,利用explain關鍵字可以模擬優化器執行SQL查詢陳述句，來分析sql慢查詢陳述句，下面我們的測驗表是一張137w資料的app資訊表，我們來舉例分析一下；

SQL示例如下：

-- 1.185s
SELECT * from vio_basic_domain_info where app_name like '%陳哈哈%' ;

??這是一條普通的模糊查詢陳述句，查詢耗時：1.185s，查到了148條資料；
??我們用Explain分析結果如下表，根據表資訊可知：該SQL沒有用到欄位app_name上的索引，查詢型別是全表掃描，掃描行數137w，

mysql> EXPLAIN SELECT * from vio_basic_domain_info where app_name like '%陳哈哈%' ;
+----+-------------+-----------------------+------------+------+---------------+------+---------+------+---------+----------+-------------+
| id | select_type | table                 | partitions | type | possible_keys | key  | key_len | ref  | rows    | filtered | Extra       |
+----+-------------+-----------------------+------------+------+---------------+------+---------+------+---------+----------+-------------+
|  1 | SIMPLE      | vio_basic_domain_info | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 1377809 |    11.11 | Using where |
+----+-------------+-----------------------+------------+------+---------------+------+---------+------+---------+----------+-------------+
1 row in set, 1 warning (0.00 sec)

??當這條SQL使用到索引時，SQL如下：查詢耗時：0.156s，查到141條資料

-- 0.156s
SELECT * from vio_basic_domain_info where app_name like '陳哈哈%' ;

??Explain分析結果如下表；根據表資訊可知：該SQL用到了idx_app_name索引，查詢型別是索引范圍查詢，掃描行數141行，由于查詢的列不全在索引中（select *），因此回表了一次，取了其他列的資料，

mysql> EXPLAIN SELECT * from vio_basic_domain_info where app_name like '陳哈哈%' ;
+----+-------------+-----------------------+------------+-------+---------------+--------------+---------+------+------+----------+-----------------------+
| id | select_type | table                 | partitions | type  | possible_keys | key          | key_len | ref  | rows | filtered | Extra                 |
+----+-------------+-----------------------+------------+-------+---------------+--------------+---------+------+------+----------+-----------------------+
|  1 | SIMPLE      | vio_basic_domain_info | NULL       | range | idx_app_name  | idx_app_name | 515     | NULL |  141 |   100.00 | Using index condition |
+----+-------------+-----------------------+------------+-------+---------------+--------------+---------+------+------+----------+-----------------------+
1 row in set, 1 warning (0.00 sec)

??當這條SQL使用到覆寫索引時，SQL如下：查詢耗時：0.091s，查到141條資料

-- 0.091s
SELECT app_name from vio_basic_domain_info where app_name like '陳哈哈%' ;

??Explain分析結果如下表；根據表資訊可知：和上面的SQL一樣使用到了索引，由于查詢列就包含在索引列中，又省去了0.06s的回表時間，

mysql> EXPLAIN SELECT app_name from vio_basic_domain_info where app_name like '陳哈哈%' ;
+----+-------------+-----------------------+------------+-------+---------------+--------------+---------+------+------+----------+--------------------------+
| id | select_type | table                 | partitions | type  | possible_keys | key          | key_len | ref  | rows | filtered | Extra                    |
+----+-------------+-----------------------+------------+-------+---------------+--------------+---------+------+------+----------+--------------------------+
|  1 | SIMPLE      | vio_basic_domain_info | NULL       | range | idx_app_name  | idx_app_name | 515     | NULL |  141 |   100.00 | Using where; Using index |
+----+-------------+-----------------------+------------+-------+---------------+--------------+---------+------+------+----------+--------------------------+
1 row in set, 1 warning (0.00 sec)

??那么是如何通過EXPLAIN決議結果分析SQL的呢？各列屬性又代表著什么？一起往下看，

2-1、各列屬性的簡介：

id:SELECT的查詢序列號，體現執行優先級，如果是子查詢，id的序號會遞增，id值越大優先級越高，越先被執行
select_type:表示查詢的型別，
table:輸出結果集的表，如設定了別名，也會顯示
partitions:匹配的磁區
type:對表的訪問方式
possible_keys:表示查詢時，可能使用的索引
key:表示實際使用的索引
key_len:索引欄位的長度
ref:列與索引的比較
rows:掃描出的行數(估算的行數)
filtered:按表條件過濾的行百分比
Extra:執行情況的描述和說明

以上標星的幾類是我們優化慢查詢時常用到的

2-2、慢查詢分析常用到的屬性

1、type：

對表訪問方式，表示MySQL在表中找到所需行的方式，又稱“訪問型別”，

存在的型別有： ALL、index、range、 ref、eq_ref、const、system、NULL（從左到右，性能從低到高），介紹三個咱們天天見到的：

ALL：(Full Table Scan) MySQL將遍歷全表以找到匹配的行，常說的全表掃描

index: (Full Index Scan) index與ALL區別為index型別只遍歷索引樹

range:只檢索給定范圍的行，使用一個索引來選擇行

2、key

??key列顯示了SQL實際使用索引，通常是possible_keys列中的索引之一，MySQL優化器一般會通過計算掃描行數來選擇更適合的索引，如果沒有選擇索引，則回傳NULL，當然，MySQL優化器存在選擇索引錯誤的情況，可以通過修改SQL強制MySQL“使用或忽視某個索引”，

強制使用一個索引：FORCE INDEX (index_name)、USE INDEX (index_name)
強制忽略一個索引：IGNORE INDEX (index_name)

3、rows

rows是MySQL估計為了找到所需的行而要讀取（掃描）的行數，可能不精確，

4、Extra

這一列顯示一些額外資訊，很重要，

Using index

??查詢的列被索引覆寫，并且where篩選條件是索引的是前導列，Extra中為Using index，意味著通過索引查找就能直接找到符合條件的資料，無須回表，

注：前導列一般指聯合索引中的第一列或“前幾列”，以及單列索引的情況；這里為了方便理解我統稱為前導列，

Using where

??說明MySQL服務器將在存盤引擎檢索行后再進行過濾；即沒有用到索引，回表查詢，

可能的原因：

查詢的列未被索引覆寫；
where篩選條件非索引的前導列或無法正確使用到索引；

Using temporary

??這意味著MySQL在對查詢結果排序時會使用一個臨時表，

Using filesort

??說明MySQL會對結果使用一個外部索引排序，而不是按索引次序從表里讀取行，

Using index condition

??查詢的列不全在索引中，where條件中是一個前導列的范圍

Using where;Using index

??查詢的列被索引覆寫，并且where篩選條件是索引列之一，但不是索引的前導列或出現了其他影響直接使用索引的情況（如存在范圍篩選條件等），Extra中為Using where; Using index，意味著無法直接通過索引查找來查詢到符合條件的資料，影響并不大，

三、一些慢查詢優化經驗分享

3-1、優化LIMIT分頁

??在系統中需要分頁的操作通常會使用limit加上偏移量的方法實作，同時加上合適的order by 子句，如果有對應的索引，通常效率會不錯，否則MySQL需要做大量的檔案排序操作，

??一個非常令人頭疼問題就是當偏移量非常大的時候，例如可能是limit 1000000,10這樣的查詢，這是mysql需要查詢1000000條然后只回傳最后10條，前面的1000000條記錄都將被舍棄，這樣的代價很高，會造成慢查詢，

??優化此類查詢的一個最簡單的方法是盡可能的使用索引覆寫掃描，而不是查詢所有的列，然后根據需要做一次關聯操作再回傳所需的列，對于偏移量很大的時候這樣做的效率會得到很大提升，

對于下面的查詢：

-- 執行耗時：1.379s
SELECT * from vio_basic_domain_info LIMIT 1000000,10;

Explain分析結果：

mysql> EXPLAIN SELECT * from vio_basic_domain_info LIMIT 1000000,10;
+----+-------------+-----------------------+------------+------+---------------+------+---------+------+---------+----------+-------+
| id | select_type | table                 | partitions | type | possible_keys | key  | key_len | ref  | rows    | filtered | Extra |
+----+-------------+-----------------------+------------+------+---------------+------+---------+------+---------+----------+-------+
|  1 | SIMPLE      | vio_basic_domain_info | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 1377809 |   100.00 | NULL  |
+----+-------------+-----------------------+------------+------+---------------+------+---------+------+---------+----------+-------+
1 row in set, 1 warning (0.00 sec)

??該陳述句存在的最大問題在于limit M,N中偏移量M太大，導致每次查詢都要先從整個表中找到滿足條件的前M條記錄，之后舍棄這M條記錄并從第M+1條記錄開始再依次找到N條滿足條件的記錄，如果表非常大，且篩選欄位沒有合適的索引，且M特別大那么這樣的代價是非常高的，

??那么如果我們下一次的查詢能從前一次查詢結束后標記的位置開始查找，找到滿足條件的10條記錄，并記下下一次查詢應該開始的位置，以便于下一次查詢能直接從該位置開始，這樣就不必每次查詢都先從整個表中先找到滿足條件的前M條記錄，舍棄掉，再從M+1開始再找到10條滿足條件的記錄了，

處理分頁慢查詢的方式一般有以下幾種

思路一：構造覆寫索引

??通過修改SQL，使用上覆寫索引，比如我需要只查詢表中的app_name、createTime等少量欄位，那么我秩序在app_name、createTime欄位設定聯合索引，即可實作覆寫索引，無需全表掃描，適用于查詢列較少的場景，查詢列數過多的不推薦，
耗時：0.390s

mysql> EXPLAIN SELECT app_name,createTime from vio_basic_domain_info LIMIT 1000000,10;
+----+-------------+-----------------------+------------+-------+---------------+--------------+---------+------+---------+----------+-------------+
| id | select_type | table                 | partitions | type  | possible_keys | key          | key_len | ref  | rows    | filtered | Extra       |
+----+-------------+-----------------------+------------+-------+---------------+--------------+---------+------+---------+----------+-------------+
|  1 | SIMPLE      | vio_basic_domain_info | NULL       | index | NULL          | idx_app_name | 515     | NULL | 1377809 |   100.00 | Using index |
+----+-------------+-----------------------+------------+-------+---------------+--------------+---------+------+---------+----------+-------------+
1 row in set, 1 warning (0.00 sec)

思路二：優化offset

??無法用上覆寫索引，那么重點是想辦法快速過濾掉前100w條資料，我們可以利用自增主鍵有序的條件，先查詢出第1000001條資料的id值，再往后查10行；適用于主鍵id自增的場景，
耗時：0.471s

SELECT * from vio_basic_domain_info where 
  id >=(SELECT id from vio_basic_domain_info ORDER BY id limit 1000000,1) limit 10;

原理：先基于索引查詢出第1000001條資料對應的主鍵id的值，然后直接通過該id的值直接查詢該id后面的10條資料，下方EXPLAIN 分析結果中大家可以看到這條SQL的兩步執行流程，

mysql> EXPLAIN SELECT * from vio_basic_domain_info where id >=(SELECT id from vio_basic_domain_info ORDER BY id limit 1000000,1) limit 10;
+----+-------------+-----------------------+------------+-------+---------------+---------+---------+------+---------+----------+-------------+
| id | select_type | table                 | partitions | type  | possible_keys | key     | key_len | ref  | rows    | filtered | Extra       |
+----+-------------+-----------------------+------------+-------+---------------+---------+---------+------+---------+----------+-------------+
|  1 | PRIMARY     | vio_basic_domain_info | NULL       | range | PRIMARY       | PRIMARY | 8       | NULL |      10 |   100.00 | Using where |
|  2 | SUBQUERY    | vio_basic_domain_info | NULL       | index | NULL          | PRIMARY | 8       | NULL | 1000001 |   100.00 | Using index |
+----+-------------+-----------------------+------------+-------+---------------+---------+---------+------+---------+----------+-------------+
2 rows in set, 1 warning (0.40 sec)

方法三：“延遲關聯”

耗時：0.439s
延遲關聯適用于數量級較大的表，SQL如下；

SELECT * from vio_basic_domain_info inner join (select id from vio_basic_domain_info order by id limit 1000000,10) as myNew using(id);

這里我們利用到了覆寫索引+延遲關聯查詢，相當于先只查詢id列，利用覆寫索引快速查到該頁的10條資料id，然后再把回傳的10條id拿到表中通過主鍵索引二次查詢，（表資料增速快的情況對該方法影響較小，）

mysql> EXPLAIN SELECT * from vio_basic_domain_info inner join (select id from vio_basic_domain_info order by id limit 1000000,10) as myNew using(id);
+----+-------------+-----------------------+------------+--------+---------------+---------+---------+----------+---------+----------+-------------+
| id | select_type | table                 | partitions | type   | possible_keys | key     | key_len | ref      | rows    | filtered | Extra       |
+----+-------------+-----------------------+------------+--------+---------------+---------+---------+----------+---------+----------+-------------+
|  1 | PRIMARY     | <derived2>            | NULL       | ALL    | NULL          | NULL    | NULL    | NULL     | 1000010 |   100.00 | NULL        |
|  1 | PRIMARY     | vio_basic_domain_info | NULL       | eq_ref | PRIMARY       | PRIMARY | 8       | myNew.id |       1 |   100.00 | NULL        |
|  2 | DERIVED     | vio_basic_domain_info | NULL       | index  | NULL          | PRIMARY | 8       | NULL     | 1000010 |   100.00 | Using index |
+----+-------------+-----------------------+------------+--------+---------------+---------+---------+----------+---------+----------+-------------+
3 rows in set, 1 warning (0.00 sec)

3-2、排查索引沒起作用的情況

模糊查詢盡量避免用通配符’%'開頭，會導致資料庫引擎放棄索引進行全表掃描，如下：

SELECT * FROM t WHERE username LIKE '%陳哈哈%'

優化方式：盡量在欄位后面使用模糊查詢，如下：

SELECT * FROM t WHERE username LIKE '陳哈哈%'

如果需求是要在前面使用模糊查詢，

使用MySQL內置函式INSTR(str,substr) 來匹配，作用類似于java中的indexOf()，查詢字串出現的角標位置，
使用FullText全文索引，用match against 檢索
資料量較大的情況，建議參考ElasticSearch、solr，億級資料量檢索速度秒級
當表資料量較少（幾千條兒那種），別整花里胡哨的，直接用like ‘%xx%’，

??但不得不說，MySQL模糊匹配大欄位是硬傷，畢竟保證事務的ACID特性耗費了太多性能，因此，如果實際場景中有類似業務需求，建議果斷更換大資料存盤引擎如ElasticSearch、Hbase等，這里和情懷無關~

盡量避免使用 not in，會導致引擎走全表掃描，建議用 not exists 代替，如下：

-- 不走索引
SELECT * FROM t WHERE name not IN ('提莫','隊長');

-- 走索引
select * from t as t1 where not exists (select * from t as t2 where name IN ('提莫','隊長') and t1.id = t2.id);

盡量避免使用 or，會導致資料庫引擎放棄索引進行全表掃描，如下：

SELECT * FROM t WHERE id = 1 OR id = 3

優化方式：可以用union代替or，如下：

SELECT * FROM t WHERE id = 1
   UNION
SELECT * FROM t WHERE id = 3

盡量避免進行null值的判斷，會導致資料庫引擎放棄索引進行全表掃描，如下：

SELECT * FROM t WHERE score IS NULL

優化方式：可以給欄位添加默認值0，對0值進行判斷，如下：

SELECT * FROM t WHERE score = 0

盡量避免在where條件中等號的左側進行運算式、函式操作，會導致資料庫引擎放棄索引進行全表掃描，

可以將運算式、函式操作移動到等號右側，如下：

-- 全表掃描
SELECT * FROM T WHERE score/10 = 9
-- 走索引
SELECT * FROM T WHERE score = 10*9

當資料量大時，避免使用where 1=1的條件，通常為了方便拼裝查詢條件，我們會默認使用該條件，資料庫引擎會放棄索引進行全表掃描，如下：

SELECT username, age, sex FROM T WHERE 1=1

優化方式：用代碼拼裝sql時進行判斷，沒 where 條件就去掉 where，有where條件就加 and，

查詢條件不要用 <> 或者 !=

使用索引列作為條件進行查詢時，需要避免使用<>或者!=等判斷條件，如確實業務需要，使用到不等于符號，需要在重新評估索引建立，避免在此欄位上建立索引，改由查詢條件中其他索引欄位代替，

where條件僅包含復合索引非前導列

??如：復合（聯合）索引包含key_part1，key_part2，key_part3三列，但SQL陳述句沒有包含索引前置列"key_part1"，按照MySQL聯合索引的最左匹配原則，不會走聯合索引，

-- 不走索引
select col1 from table where key_part2=1 and key_part3=2
-- 走索引
select col1 from table where key_part1 =1 and key_part2=1 and key_part3=2

隱式型別轉換造成不使用索引

??如下SQL陳述句由于索引對列型別為varchar，但給定的值為數值，涉及隱式型別轉換，造成不能正確走索引，

select col1 from table where col_varchar=123;

總結

??好了，通過這篇文章，希望你Get到了一些分析MySQL慢查詢的方法和心得，慢查詢，在MySQL中始終是繞不開的話題，慢的方式多種多樣，如果你想完全避免慢查詢？年輕人，我建議你耗子尾汁~

??我們需要做的是及時發現并解決慢查詢，其實很多慢查詢是被動出現的，比如由于某業務資料量猛增數量級變化、由于業務需求變化而改了欄位或操作了既有索引等，雖然不是你的錯，但這鍋可能還得你來背🙃🙃🙃🙃
在這里插入圖片描述

??如果你覺得這篇文章不錯，記得分享給朋友或同事，讓大家少踩點坑，

MySQL系列文章匯總與《MySQL江湖路 | 專欄目錄》

往期熱門MySQL系列文章：

原創 | MySQL中特別實用的幾種SQL陳述句送給大家
原創 | SQL優化最干貨總結 - MySQL（2020最新版）
原創 | 為什么大家都說SELECT * 效率低
原創 | 面試讓HR都能聽懂的MySQL鎖機制，歡聲笑語中搞懂MySQL鎖
原創 | MySQL中的 utf8 并不是真正的UTF-8編碼 ! !
原創 | MySQL資料中有很多換行符和回車符！！該咋辦？
原創 | delete后加 limit是個好習慣么

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/280739.html

標籤：其他

上一篇：學會這八個技術，你離BAT大廠不遠了

MySQL慢查詢，一口從天而降的鍋！

目錄

一、慢查詢配置

1-1、開啟慢查詢

方式一：通過命令開啟慢查詢

方式二：通過配置my.cnf（windows是my.ini）系統檔案開啟

1-2、慢查詢日志介紹

二、Explain分析慢查詢SQL

2-1、各列屬性的簡介：

2-2、慢查詢分析常用到的屬性

1、type：

2、key

3、rows

4、Extra

三、一些慢查詢優化經驗分享

3-1、優化LIMIT分頁

思路一：構造覆寫索引

思路二：優化offset

方法三：“延遲關聯”

3-2、排查索引沒起作用的情況

總結