千萬級使用者系統SQL調優實戰分享

使用者日活百萬級，註冊使用者千萬級，而且若還沒有進行分庫分表，則該DB裡的使用者表可能就一張，單表上千萬的使用者資料。

某系統專門通過各種條件篩選大量使用者，接著對那些使用者去推播一些訊息：

• 一些促銷活動訊息
• 讓你辦會員卡的訊息
• 告訴你有一個特價商品的訊息

通過一些條件篩選出大量使用者，針對這些使用者做推播，該過程較耗時-篩選使用者過程。

使用者日活百萬級，註冊使用者千萬級，而且若還沒有進行分庫分表，則該DB裡的使用者表可能就一張，單表上千萬的使用者資料。

對運營系統篩選使用者的SQL：

SELECT id, name 
FROM users 
WHERE id IN (
  SELECT user_id 
  FROM users_extent_info 
  WHERE latest_login_time < xxxxx
) 

一般儲存使用者資料的表會分為兩張表：

• 儲存使用者的核心資料，如id、name、暱稱、手機號之類的資訊，也就是上面SQL語句裡的users表
• 儲存使用者的一些拓展資訊，比如說家庭住址、興趣愛好、最近一次登入時間之類的，即users_extent_info表

有個子查詢，裡面針對使用者的拓展資訊表，即users_extent_info查下最近一次登入時間<某個時間點的使用者，可以查詢最近才登入過的使用者，也可查詢很長時間未登入的使用者，然後給他們發push，無論哪種場景， 該SQL都適用。

然後在外層查詢，用id IN子句查詢 id 在子查詢結果範圍裡的users表的所有資料，此時該SQL突然會查出很多資料，可能幾千、幾萬、幾十萬，所以執行此類SQL前，都會先執行count：

SELECT COUNT(id)
FROM users
WHERE id IN (
    SELECT user_id
    FROM users_extent_info
    WHERE latest_login_time < xxxxx
    )

然後記憶體裡做個小批次，多批次讀取資料的操作，比如判斷如果在1000條以內，那麼就一下子讀取出來，若超過1000條，可通過LIMIT語句，每次就從該結果集裡查1000條資料，查1000條就做次批次PUSH，再查下一波1000條。

就是在千萬級資料量大表場景下，上面SQL直接輕鬆跑出來耗時幾十s，不優化不行!

今天咱們繼續來看這個千萬級使用者場景下的運營系統SQL調優案例，上次已經給大家說了一下業務背景 以及SQL，這個SQL就是如下的一個：

SELECT COUNT(id) FROM users WHERE id IN (SELECT user_id FROM 
users_extent_info WHERE latest_login_time < xxxxx)

系統執行時，先COUNT查該結果集有多少資料，再分批查詢。然而COUNT在千萬級大表場景下，都要花幾十s。實際上每個不同的MySQL版本都可能會調整生成執行計劃的方式。

通過：

EXPLAIN 
SELECT COUNT(id) 
FROM users 
WHERE id IN (
  SELECT user_id 
  FROM users_extent_info 
  WHERE latest_login_time < xxxxx
)

如下執行計劃是為了調優，在測試環境的單表2萬條資料場景，即使是5萬條資料，當時這個SQL都跑了十多s，注意執行計劃裡的資料量

執行計劃裡的第三行

先子查詢，針對users_extent_info，使用idx_login_time索引，做了range型別的索引範圍掃描，查出4561條資料，沒有做額外篩選，所以filtered=100%。

MATERIALIZED：這裡把子查詢的4561條資料代表的結果集進行了物化，物化成了一個臨時表，這個臨時表物化，一定是會把4561條資料臨時落到磁碟檔案裡去的，這過程很慢。

第二條執行計劃

針對users表做了一個全表掃描，在全表掃描的時候掃出來49651條資料，Extra=Using join buffer，此處居然在執行join。

執行計劃裡的第一條

針對子查詢產出的一個物化臨時表，即做了個全表查詢，把裡面的資料都掃描了一遍。

為何對這臨時表進行全表掃描?讓users表的每條資料都和物化臨時表裡的資料進行join，所以針對users表裡的每條資料，只能是去全表掃描一遍物化臨時表，從物化臨時表裡確認哪條資料和他匹配，才能篩選出一條結果。

第二條執行計劃的全表掃描結果表明一共掃到49651條，但全表掃描過程中，因為和物化臨時表執行join，而物化臨時表裡就4561條資料，所以最終第二條執行計劃的filtered=10%，即最終從users表裡也篩選出4000多條資料。

到底為什麼慢

| id | select_type | table | type | key | rows | filtered | Extra |

+----+-------------+-------+------------+-------+---------------+----------+---------+---

| 1 | SIMPLE | | ALL | NULL | NULL | 100.00 | NULL |

| 1 | SIMPLE | users | ALL | NULL | 49651 | 10.00 | Using where; Using join buffer(Block Nested Loop) |

| 2 | MATERIALIZED | users_extent_info | range | idx_login_time | 4561 | 100.00 | NULL |

先執行了子查詢查出4561條資料，物化成臨時表，接著對users主表全表掃描，掃描過程把每條資料都放到物化臨時表裡做全表掃描，本質在做join。

對子查詢的結果做了一次物化臨時表，落地磁碟，接著還全表掃描users表，每條資料居然跑到一個沒有索引的物化臨時表裡，又做了一次全表掃描找匹配的資料。

對users表的全表掃描耗時嗎?

對users表的每一條資料跑到物化臨時表裡做全表掃描耗時嗎?

所以必然非常慢，幾乎用不到索引。為什麼MySQL會這樣呢?

執行完上述SQL的EXPLAIN命令，看到執行計劃之後，再執行：

show warnings

顯示出：

/* select#1 */ select count( d2. users . user_id `) AS 
COUNT(users.user_id)`
from d2 . users users semi join xxxxxx

注意： semi join ，MySQL在這裡，生成執行計劃的時候，自動就把一個普通IN子句，“優化”成基於semi join來進行IN+子查詢的操作。那對users表不是全表掃描了嗎?對users表裡每條資料，去對物化臨時表全表掃描做semi join，無需將users表裡的資料真的跟物化臨時表裡的資料join。只要users表裡的一條資料，在物化臨時表能找到匹配資料，則users表裡的資料就會返回，這就是semi join，用來做篩選。

所以就是semi join和物化臨時表導致的慢題，那怎麼優化?

做個實驗

執行：

SET optimizer_switch='semijoin=off'

關閉半連線優化，再執行EXPLAIN發現恢復為正常狀態：

有個SUBQUERY子查詢，基於range方式去掃描索引，搜尋出4561條資料
接著有個PRIMARY型別主查詢，直接基於id這個PRIMARY主鍵聚簇索引去執行的搜尋
然後再把這個SQL語句真實跑一下看看，效能竟然提升了幾十倍，僅100多ms。
所以，其實反而是MySQL自動執行的semi join半連線優化，導致了極差效能，關閉即可。

生產環境當然不能隨意更改這些設定，於是想了多種辦法嘗試去修改SQL語句的寫法，在不影響其語意情況下，儘可能改變SQL語句的結構和格式，

最終嘗試出如下寫法：

SELECT COUNT(id)
FROM users
WHERE (
    id IN (
        SELECT user_id
        FROM users_extent_info
        WHERE latest_login_time < xxxxx) 
        OR
    id IN (
        SELECT user_id
        FROM users_extent_info
        WHERE latest_login_time < -1)
)

上述寫法下，WHERE語句的OR後面的第二個條件，根本不可能成立，因為沒有資料的latest_login_time<-1，所以那不會影響SQL業務語意，但改變SQL後，執行計劃也會變，就沒有再semi join優化了，而是常規地用了子查詢，主查詢也是基於索引，同樣達到幾百ms 效能優化。

所以最核心的，還是看懂SQL執行計劃，分析慢的原因，儘量避免全表掃描，務必用上索引。

到此這篇關於千萬級使用者系統SQL調優實戰分享的文章就介紹到這了,更多相關SQL調優實戰內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com！