盗墓笔记全集,小说排行榜完结版,琅琊榜海宴小说

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

千萬級(jí)用戶系統(tǒng)的SQL調(diào)優(yōu)實(shí)戰(zhàn)

某系統(tǒng)專門通過各種條件篩選大量用戶，接著對(duì)那些用戶去推送一些消息：

專注于為中小企業(yè)提供成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)服務(wù),電腦端+手機(jī)端+微信端的三站合一,更高效的管理,為中小企業(yè)青陽免費(fèi)做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動(dòng)了成百上千企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實(shí)現(xiàn)規(guī)模擴(kuò)充和轉(zhuǎn)變。

一些促銷活動(dòng)消息
讓你辦會(huì)員卡的消息
告訴你有一個(gè)特價(jià)商品的消息

通過一些條件篩選出大量用戶，針對(duì)這些用戶做推送，該過程較耗時(shí)-篩選用戶過程。

用戶日活百萬級(jí)，注冊(cè)用戶千萬級(jí)，而且若還沒有進(jìn)行分庫分表，則該DB里的用戶表可能就一張，單表上千萬的用戶數(shù)據(jù)。

對(duì)運(yùn)營系統(tǒng)篩選用戶的SQL：

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

一般存儲(chǔ)用戶數(shù)據(jù)的表會(huì)分為兩張表：

存儲(chǔ)用戶的核心數(shù)據(jù)，如id、name、昵稱、手機(jī)號(hào)之類的信息，也就是上面SQL語句里的users表
存儲(chǔ)用戶的一些拓展信息，比如說家庭住址、興趣愛好、最近一次登錄時(shí)間之類的，即users_extent_info表

有個(gè)子查詢，里面針對(duì)用戶的拓展信息表，即users_extent_info查下最近一次登錄時(shí)間<某個(gè)時(shí)間點(diǎn)的用戶，可以查詢最近才登錄過的用戶，也可查詢很長時(shí)間未登錄的用戶，然后給他們發(fā)push，無論哪種場(chǎng)景，該SQL都適用。

然后在外層查詢，用id IN子句查詢 id 在子查詢結(jié)果范圍里的users表的所有數(shù)據(jù)，此時(shí)該SQL突然會(huì)查出很多數(shù)據(jù)，可能幾千、幾萬、幾十萬，所以執(zhí)行此類SQL前，都會(huì)先執(zhí)行count：

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

然后內(nèi)存里做個(gè)小批量，多批次讀取數(shù)據(jù)的操作，比如判斷如果在1000條以內(nèi)，那么就一下子讀取出來，若超過1000條，可通過LIMIT語句，每次就從該結(jié)果集里查1000條數(shù)據(jù)，查1000條就做次批量PUSH，再查下一波1000條。

就是在千萬級(jí)數(shù)據(jù)量大表場(chǎng)景下，上面SQL直接輕松跑出來耗時(shí)幾十s，不優(yōu)化不行!

今天咱們繼續(xù)來看這個(gè)千萬級(jí)用戶場(chǎng)景下的運(yùn)營系統(tǒng)SQL調(diào)優(yōu)案例，上次已經(jīng)給大家說了一下業(yè)務(wù)背景以及SQL，這個(gè)SQL就是如下的一個(gè)：

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

系統(tǒng)運(yùn)行時(shí)，先COUNT查該結(jié)果集有多少數(shù)據(jù)，再分批查詢。然而COUNT在千萬級(jí)大表場(chǎng)景下，都要花幾十s。實(shí)際上每個(gè)不同的MySQL版本都可能會(huì)調(diào)整生成執(zhí)行計(jì)劃的方式。

通過：

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

如下執(zhí)行計(jì)劃是為了調(diào)優(yōu)，在測(cè)試環(huán)境的單表2萬條數(shù)據(jù)場(chǎng)景，即使是5萬條數(shù)據(jù)，當(dāng)時(shí)這個(gè)SQL都跑了十多s，注意執(zhí)行計(jì)劃里的數(shù)據(jù)量

執(zhí)行計(jì)劃里的第三行

先子查詢，針對(duì)users_extent_info，使用idx_login_time索引，做了range類型的索引范圍掃描，查出4561條數(shù)據(jù)，沒有做額外篩選，所以?ltered=100%。

MATERIALIZED：這里把子查詢的4561條數(shù)據(jù)代表的結(jié)果集進(jìn)行了物化，物化成了一個(gè)臨時(shí)表，這個(gè)臨時(shí)表物化，一定是會(huì)把4561條數(shù)據(jù)臨時(shí)落到磁盤文件里去的，這過程很慢。

第二條執(zhí)行計(jì)劃

針對(duì)users表做了一個(gè)全表掃描，在全表掃描的時(shí)候掃出來49651條數(shù)據(jù)，Extra=Using join bu?er，此處居然在執(zhí)行join。

執(zhí)行計(jì)劃里的第一條

針對(duì)子查詢產(chǎn)出的一個(gè)物化臨時(shí)表，即做了個(gè)全表查詢，把里面的數(shù)據(jù)都掃描了一遍。

為何對(duì)這臨時(shí)表進(jìn)行全表掃描?讓users表的每條數(shù)據(jù)都和物化臨時(shí)表里的數(shù)據(jù)進(jìn)行join，所以針對(duì)users表里的每條數(shù)據(jù)，只能是去全表掃描一遍物化臨時(shí)表，從物化臨時(shí)表里確認(rèn)哪條數(shù)據(jù)和他匹配，才能篩選出一條結(jié)果。

第二條執(zhí)行計(jì)劃的全表掃描結(jié)果表明一共掃到49651條，但全表掃描過程中，因?yàn)楹臀锘R時(shí)表執(zhí)行join，而物化臨時(shí)表里就4561條數(shù)據(jù)，所以最終第二條執(zhí)行計(jì)劃的?ltered=10%，即最終從users表里也篩選出4000多條數(shù)據(jù)。

到底為什么慢

| id | select_type | table | type | key | rows | ?ltered | Extra |

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

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

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

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

先執(zhí)行了子查詢查出4561條數(shù)據(jù)，物化成臨時(shí)表，接著對(duì)users主表全表掃描，掃描過程把每條數(shù)據(jù)都放到物化臨時(shí)表里做全表掃描，本質(zhì)在做join。

對(duì)子查詢的結(jié)果做了一次物化臨時(shí)表，落地磁盤，接著還全表掃描users表，每條數(shù)據(jù)居然跑到一個(gè)沒有索引的物化臨時(shí)表里，又做了一次全表掃描找匹配的數(shù)據(jù)。

對(duì)users表的全表掃描耗時(shí)嗎?

對(duì)users表的每一條數(shù)據(jù)跑到物化臨時(shí)表里做全表掃描耗時(shí)嗎?

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

執(zhí)行完上述SQL的EXPLAIN命令，看到執(zhí)行計(jì)劃之后，再執(zhí)行：

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在這里，生成執(zhí)行計(jì)劃的時(shí)候，自動(dòng)就把一個(gè)普通IN子句，“優(yōu)化”成基于semi join來進(jìn)行IN+子查詢的操作。那對(duì)users表不是全表掃描了嗎?對(duì)users表里每條數(shù)據(jù)，去對(duì)物化臨時(shí)表全表掃描做semi join，無需將users表里的數(shù)據(jù)真的跟物化臨時(shí)表里的數(shù)據(jù)join。只要users表里的一條數(shù)據(jù)，在物化臨時(shí)表能找到匹配數(shù)據(jù)，則users表里的數(shù)據(jù)就會(huì)返回，這就是semi join，用來做篩選。

所以就是semi join和物化臨時(shí)表導(dǎo)致的慢題，那怎么優(yōu)化?

做個(gè)實(shí)驗(yàn)

執(zhí)行

SET optimizer_switch='semijoin=o?'

關(guān)閉半連接優(yōu)化，再執(zhí)行EXPLAIN發(fā)現(xiàn)恢復(fù)為正常狀態(tài)：

有個(gè)SUBQUERY子查詢，基于range方式去掃描索引，搜索出4561條數(shù)據(jù)
接著有個(gè)PRIMARY類型主查詢，直接基于id這個(gè)PRIMARY主鍵聚簇索引去執(zhí)行的搜索
然后再把這個(gè)SQL語句真實(shí)跑一下看看，性能竟然提升了幾十倍，僅100多ms。

所以，其實(shí)反而是MySQL自動(dòng)執(zhí)行的semi join半連接優(yōu)化，導(dǎo)致了極差性能，關(guān)閉即可。

生產(chǎn)環(huán)境當(dāng)然不能隨意更改這些設(shè)置，于是想了多種辦法嘗試去修改SQL語句的寫法，在不影響其語義情況下，盡可能改變SQL語句的結(jié)構(gòu)和格式，最終嘗試出如下寫法：

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后面的第二個(gè)條件，根本不可能成立，因?yàn)闆]有數(shù)據(jù)的latest_login_time<-1，所以那不會(huì)影響SQL業(yè)務(wù)語義，但改變SQL后，執(zhí)行計(jì)劃也會(huì)變，就沒有再semi join優(yōu)化了，而是常規(guī)地用了子查詢，主查詢也是基于索引，同樣達(dá)到幾百ms 性能優(yōu)化。

所以最核心的，還是看懂SQL執(zhí)行計(jì)劃，分析慢的原因，盡量避免全表掃描，務(wù)必用上索引。

分享標(biāo)題：千萬級(jí)用戶系統(tǒng)的SQL調(diào)優(yōu)實(shí)戰(zhàn)
文章分享：http://m.fisionsoft.com.cn/article/cdieoih.html

新聞中心

到底為什么慢

show warnings

做個(gè)實(shí)驗(yàn)

其他資訊