背景
今年3月份時(shí)候，線上發(fā)生一次大事故。公司主要后端服務(wù)器發(fā)生宕機(jī)，所有接口超時(shí)。宕機(jī)半小時(shí)后，又自動恢復(fù)正常。但是過了2小時(shí)，又再次發(fā)生宕機(jī)。
通過接口日志，發(fā)現(xiàn)MySQL數(shù)據(jù)庫無法響應(yīng)服務(wù)器。在阿里云的技術(shù)支持的幫助下，發(fā)現(xiàn)了MySQL數(shù)據(jù)庫中存在大量慢查詢，導(dǎo)致CPU負(fù)載過高。最后，根據(jù)慢查詢?nèi)罩荆ㄎ坏搅顺鰡栴}的SQL和業(yè)務(wù)接口。
業(yè)務(wù)接口是一個(gè)分頁接口，莫名被刷到7000多頁，偏移量（offset）高達(dá)20w多。每當(dāng)這條SQL執(zhí)行時(shí)，數(shù)據(jù)庫CPU直接打滿。查詢時(shí)間超過1分鐘才有響應(yīng)。由于慢查詢導(dǎo)致數(shù)據(jù)庫CPU使用率爆滿，其他業(yè)務(wù)的數(shù)據(jù)庫請求無法得到及時(shí)響應(yīng)，接口超時(shí)。最后，拖垮主服務(wù)器。
limit分頁查詢性能問題
MySQL Limit 語法格式：
SELECT * FROM table LIMIT [offset,] rows | rows OFFSET offset
分頁查詢時(shí)，我們會在 LIMIT 后面?zhèn)鲀蓚€(gè)參數(shù)，一個(gè)是偏移量（offset），一個(gè)是獲取的條數(shù)（limit）。當(dāng)偏移量很小時(shí)，查詢速度很快，但是當(dāng) offset 很大時(shí)，查詢速度就會變慢。
下面我們以一個(gè)實(shí)例，講解一下分頁性能問題。假設(shè)有一張 300w 條數(shù)據(jù)的表，對其進(jìn)行分頁查詢。
select * from tbl_works limit 1, 10 // 32.8ms
select * from tbl_works limit 10, 10 // 34.2ms
select * from tbl_works limit 100, 10 // 35.4ms
select * from tbl_works limit 1000, 10 // 39.6ms
select * from tbl_works limit 10000, 10 // 5660ms
select * from tbl_works limit 100000, 10 // 61.4 秒
select * from tbl_works limit 1000000, 10 // 273 秒
可以看到，隨著偏移量（offset）的增加，查詢時(shí)間變得越長。對于普通的業(yè)務(wù)而言，超過1秒的查詢是絕對不可以忍受的。上例中，當(dāng)偏移的起始位置超過10萬時(shí)，分頁查詢的時(shí)間超過61秒。當(dāng)偏移量超過100萬時(shí)，查詢時(shí)間竟然長達(dá)273秒。
從上例中，我們可以總結(jié)出：LIMIT分頁查詢的時(shí)間與偏移量值成正比。當(dāng)偏移量越大時(shí)，查詢時(shí)間越長。這種情況，會隨著業(yè)務(wù)的增加，數(shù)據(jù)的增多，會越發(fā)的明顯。那么，如何優(yōu)化這種情況呢？答案是，覆蓋索引。
優(yōu)化方法
對于LIMIT分頁查詢的性能優(yōu)化，主要思路是利用覆蓋索引字段定位數(shù)據(jù)，然后再取出內(nèi)容。
不使用覆蓋索引，查詢耗時(shí)情況：
SELECT * FROM `tbl_works`
WHERE `status`=1
LIMIT 100000, 10 // 78.3 秒
1）子查詢分頁方式
SELECT * FROM tbl_works
WHERE id >= (SELECT id FROM tbl_works limit 100000, 1)
LIMIT 20 // 54ms
子查詢分頁方式，首先通過子查詢和覆蓋索引定位到起始位置ID，然后再取所需條數(shù)的數(shù)據(jù)。
缺點(diǎn)是，不適用于結(jié)果集不以ID連續(xù)自增的分頁場景。在復(fù)雜分頁場景，往往需要通過過濾條件，篩選到符合條件的ID，此時(shí)的ID是離散且不連續(xù)的。如果使用上述的方式，并不能篩選出目標(biāo)數(shù)據(jù)。
當(dāng)然，我們也可以對此方法做一些改進(jìn)，首先利用子查詢獲取目標(biāo)分頁的 ids，然后再根據(jù) ids 獲取內(nèi)容。
根據(jù)直覺將SQL改造如下：
SELECT * FROM tbl_works
WHERE id IN (SELECT id FROM tbl_works limit 100000, 10)
// 錯(cuò)誤信息：
// This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery'
然而，并不盡人意。我們得到一個(gè)錯(cuò)誤提示。
錯(cuò)誤信息的含義是，子查詢不能有 limit操作。于是，我們對SQL進(jìn)行了改造，對子查詢包了一層：
SELECT t1.* FROM tbl_works t1
WHERE t1.id in (SELECT t2.id from (SELECT id FROM tbl_works limit 100000, 10) as t2) // 53.9ms
執(zhí)行成功，且查詢效率很高。但是，這種寫法非常繁瑣。我們可以使用下面的 join 分頁方式，達(dá)到相同的優(yōu)化效果。實(shí)際上，兩者的原理是相同的。
2）join 分頁方式
SELECT * FROM tbl_works t1
JOIN (SELECT id from tbl_works WHERE status=1
limit 100000, 10) t2
ON t1.id = t2.id // 53.6 ms
這條SQL的含義是，通過自連接與join定位到目標(biāo) ids，然后再將數(shù)據(jù)取出。在定位目標(biāo) ids時(shí)，由于 SELECT的元素只有主鍵 ID，且status 存在索引，因此MySQL只需在索引中，就能定位到目標(biāo) ids，不用在數(shù)據(jù)文件上進(jìn)行查找。因而，查詢效率非常高。
覆蓋索引（Cover Index）
如果索引包含所有滿足查詢需要的數(shù)據(jù)的索引成為覆蓋索引(Covering Index)，也就是平時(shí)所說的不需要回表操作。
簡單的說，覆蓋索引覆蓋所有需要查詢的字段（即，大于或等于所查詢的字段）。MySQL可以通過索引獲取查詢數(shù)據(jù)，因而不需要讀取數(shù)據(jù)行。
覆蓋索引的好處：
- 索引大小遠(yuǎn)小于數(shù)據(jù)行大小。因而，如果只讀取索引，則能極大減少對數(shù)據(jù)訪問量。
- 索引按順序儲存。對于IO密集型的范圍查詢會比隨機(jī)從磁盤讀取每一行數(shù)據(jù)的IO要少。
- 避免對主鍵索引的二次查詢。二級索引的葉子節(jié)點(diǎn)包含了主鍵的值，如果二級索引包含所要查詢的值，則能避免二次查詢主鍵索引（聚簇索引，聚簇索引既存儲了索引，也儲存了值）。
總結(jié)
通過利用覆蓋索引，能極大的優(yōu)化了Limit分頁查詢的效率。在真正的實(shí)踐中，除了使用覆蓋索引，優(yōu)化查詢速度外，我們還可以使用 Redis 緩存，將熱點(diǎn)數(shù)據(jù)進(jìn)行緩存儲存。
背景描述的事故，我們考慮了時(shí)間成本和業(yè)務(wù)復(fù)雜度后，最后采取的是限制分頁和增加緩存。所謂的限制分頁，即在不影響閱讀體驗(yàn)的前提下，只允許用戶可以查看前幾千條的數(shù)據(jù)。經(jīng)測驗(yàn)，偏移量較小時(shí)的查詢效率較令人滿意，查詢效率接近使用覆蓋索引查詢的速度。
