PolarDB千億級(jí)大表優(yōu)化實(shí)踐：分布式架構(gòu)與性能調(diào)優(yōu)指南

單表數(shù)據(jù)量突破千億行后，數(shù)據(jù)庫性能與維護(hù)成本成倍惡化，單純依賴分庫分表中間件很難根治。在 PolarDB 千億級(jí)大表優(yōu)化實(shí)踐中，通過存儲(chǔ)計(jì)算分離、透明分布式與冷熱數(shù)據(jù)分層，可以在不侵入應(yīng)用的前提下實(shí)現(xiàn)彈性擴(kuò)展、秒級(jí)在線 DDL，把存儲(chǔ)成本壓縮到傳統(tǒng)方案的幾十分之一。

一、千億級(jí)大表面臨的核心挑戰(zhàn)

1. 大表帶來哪些痛點(diǎn)？

單表行數(shù)超過千萬時(shí)，MySQL 的 B+ 樹索引深度急劇增加，分析型 SQL 經(jīng)常無法跑出結(jié)果。達(dá)到千億級(jí)別后，任何一次 DDL（如加列、建索引）都會(huì)長時(shí)間鎖表，直接阻斷業(yè)務(wù)。歷史數(shù)據(jù)清理同樣棘手：按時(shí)間范圍刪數(shù)據(jù)容易引發(fā)大事務(wù)回滾，表空間無法及時(shí)回收。再加上原始數(shù)據(jù)與多套二級(jí)索引的累積，總存儲(chǔ)量可到 PB 級(jí)，基于全閃存三副本的存儲(chǔ)成本變得難以承受。

2. 傳統(tǒng)方案為何失效？

應(yīng)用層分庫分表會(huì)讓分片鍵邏輯侵入業(yè)務(wù)代碼，跨分片查詢和分布式事務(wù)的復(fù)雜度驟升。寄望于增加索引來提速，但每多一個(gè)二級(jí)索引都會(huì)帶來顯著寫放大，全局索引還要背負(fù)分布式事務(wù)開銷，很容易反過來拖慢寫入。遷移方案也充滿風(fēng)險(xiǎn)：DTS 全量同步千億行數(shù)據(jù)可能耗時(shí)數(shù)天，增量階段一旦出現(xiàn)數(shù)據(jù)不一致，幾乎沒有簡單有效的自動(dòng)修復(fù)手段，必須在業(yè)務(wù)低峰期搭配數(shù)據(jù)校驗(yàn)和反向回滾才能保障平滑切換。

3. PolarDB 的解決思路

PolarDB 將解決方案下沉到內(nèi)核層。透明分布式意味著分片策略對(duì)應(yīng)用完全隱式，單表可支撐百萬級(jí)物理分片，承載千億行以上的數(shù)據(jù)量。計(jì)算與存儲(chǔ)分離后，寫節(jié)點(diǎn)產(chǎn)生的 Redo 日志能以毫秒級(jí)延遲應(yīng)用到讀節(jié)點(diǎn)，避免邏輯復(fù)制在大事務(wù)場(chǎng)景下的延遲抖動(dòng)。配合按時(shí)間 + 用戶 ID 的級(jí)聯(lián)分區(qū)、全局二級(jí)索引，絕大多數(shù)查詢可以精準(zhǔn)定位到單個(gè)分片，而 Fast-DDL 僅修改元數(shù)據(jù)即可在秒級(jí)完成千億行表的加列操作，全程不阻塞讀寫。

二、PolarDB分布式架構(gòu)深度解析

面對(duì)單表單日數(shù)十億行的寫入、歷史數(shù)據(jù)堆積至千億行后，存儲(chǔ)成本與查詢延遲雙雙失控的困境，依靠傳統(tǒng)分庫分表中間件在應(yīng)用層打補(bǔ)丁的做法，已顯現(xiàn)出明顯的天花板：分片鍵與路由邏輯的強(qiáng)耦合，讓每次業(yè)務(wù)迭代都像在走鋼絲；跨分片分布式事務(wù)的代價(jià)，又常使性能退回到單機(jī)時(shí)代。真正能化解千億級(jí)大表壓力的，并不是更復(fù)雜的中間件配置，而是一個(gè)從存儲(chǔ)、計(jì)算到元數(shù)據(jù)管理都內(nèi)建分布式能力的數(shù)據(jù)庫內(nèi)核。這便需要重新審視云原生架構(gòu)下，共享存儲(chǔ)、存算分離、透明分片以及主備復(fù)制之間的工程取舍。

1. 共享存儲(chǔ)與存算分離：從物理復(fù)制到瞬時(shí)一致性

傳統(tǒng)主備架構(gòu)依賴 Binlog 邏輯復(fù)制，大事務(wù)會(huì)產(chǎn)生數(shù) GB 的 Binlog 文件，備機(jī)回放延遲隨之飆升到分鐘級(jí)，恰好與千億級(jí)大表頻繁的批量寫入形成死結(jié)。而 PolarDB 選擇的路徑是徹底的計(jì)算存儲(chǔ)分離——所有計(jì)算節(jié)點(diǎn)共享同一份位于 PolarFileSystem 上的分布式存儲(chǔ)，主節(jié)點(diǎn)寫出的 Redo 日志無需經(jīng)過邏輯轉(zhuǎn)換，直接在存儲(chǔ)層就被備節(jié)點(diǎn)即時(shí)消費(fèi)，物理復(fù)制的延遲控制在毫秒級(jí)別。這意味著，即使是千億行大表上的大規(guī)模更新或索引重建，主備之間的數(shù)據(jù)延遲也不會(huì)出現(xiàn)不可控的放大。

這一設(shè)計(jì)的現(xiàn)實(shí)價(jià)值，在只讀實(shí)例擴(kuò)展上體現(xiàn)得尤為直接。一家物流軌跡平臺(tái)，在單表 5000 億行的規(guī)模下，將實(shí)時(shí)軌跡寫入限定在主實(shí)例，將所有對(duì)外的軌跡查詢、報(bào)表分析全部分流到 10 個(gè)只讀節(jié)點(diǎn)，且開啟了全局一致性讀。由于只讀節(jié)點(diǎn)與主節(jié)點(diǎn)共享同一份存儲(chǔ)視圖，應(yīng)用無需擔(dān)憂“讀到舊數(shù)據(jù)”，避免了在應(yīng)用層引入復(fù)雜的讀修復(fù)邏輯。數(shù)據(jù)表明，其查詢端的平均延遲下降了 72%，而存儲(chǔ)成本因多節(jié)點(diǎn)共享同一份數(shù)據(jù)，相比各自維護(hù)全套副本的部署方式，節(jié)省了超過 40% 的磁盤開銷。這種架構(gòu)本質(zhì)上把“一份數(shù)據(jù)、多種計(jì)算”的彈性發(fā)揮到了極致——不再為查詢高峰而被迫為寫入節(jié)點(diǎn)購買多余的計(jì)算資源。

2. 透明分布式與讀寫分離：消解分片鍵的詛咒

千億行大表落地時(shí)，最折磨人的技術(shù)債莫過于分片鍵的選擇。選錯(cuò)了，應(yīng)用幾乎不能幸免于全分片掃描；選對(duì)了，又可能因?yàn)闃I(yè)務(wù)形態(tài)變化而失效。PolarDB-X 的透明分布式方案，把分片策略從應(yīng)用代碼提升到內(nèi)核層：系統(tǒng)可依據(jù)數(shù)據(jù)量自動(dòng)將邏輯表切分成數(shù)百萬級(jí)物理分片，對(duì)上層 JDBC/ORM 完全透明。這樣一來，核心改造工作從“應(yīng)用逐行改造 SQL”轉(zhuǎn)變?yōu)椤岸x分區(qū)策略”，風(fēng)險(xiǎn)面大大收窄。

具體的策略上，單純依賴 HASH 分區(qū)會(huì)丟失范圍查詢的優(yōu)化空間，單純 RANGE 分區(qū)則容易在時(shí)間維度上產(chǎn)生熱點(diǎn)。工程實(shí)踐中，使用得最穩(wěn)健的模式是兩級(jí)級(jí)聯(lián)分區(qū)——以訂單表為例，先用 user_id 做一級(jí) HASH 分區(qū)來均衡寫入壓力，再按時(shí)間字段做二級(jí) RANGE 分區(qū)，實(shí)現(xiàn)按天或按月的快速歸檔。全局二級(jí)索引（GSI）則補(bǔ)齊了另一塊短板：當(dāng)查詢條件偏離主表分區(qū)鍵時(shí)（例如按商戶 ID 或訂單狀態(tài)查詢），GSI 能獨(dú)立于主表的分區(qū)維度精準(zhǔn)定位到單個(gè)或少數(shù)幾個(gè)分片，避免跨節(jié)點(diǎn)數(shù)據(jù)匯聚。真實(shí)的查詢壓測(cè)顯示，在 800 億行表上，使用 GSI 后的多維度查詢可將實(shí)際掃描行數(shù)降低 3 至 4 個(gè)數(shù)量級(jí)，延遲從分鐘級(jí)壓縮到百毫秒級(jí)。

讀寫分離同樣不是簡單的“主寫只讀”分流就足夠。千億行表中，統(tǒng)計(jì)類 SQL 極容易耗盡讀節(jié)點(diǎn) CPU 資源，擠壓其他只讀請(qǐng)求。合理的配置，是利用并行查詢能力，通過調(diào)整 max_parallel_degree 將這些大查詢的計(jì)算拆解到多核上，配合只讀實(shí)例的獨(dú)立資源池，實(shí)現(xiàn)了隔離與加速的雙重目的。同時(shí)，利用 PolarDB 的 Fast-DDL 能力，千億行表的加列操作只需在元數(shù)據(jù)層面提交一次變更，秒級(jí)完成而無需拷貝任何數(shù)據(jù)，徹底打破了“大表不敢改”的枷鎖。這些機(jī)制疊加起來，讓千億級(jí)大表的運(yùn)維從過去的季度級(jí)別的翼翼小心，過渡到可以頻繁響應(yīng)的日常迭代節(jié)奏。

三、大表數(shù)據(jù)分片與分區(qū)策略

當(dāng)單表突破千億行，數(shù)據(jù)不再是一張能靠硬件硬撐的“大表”，而是一個(gè)必須拆解的存儲(chǔ)與計(jì)算單元。PolarDB-X 的透明分布式能力將拆分邏輯下沉到內(nèi)核，應(yīng)用層可以不感知分片鍵，但架構(gòu)師必須理解背后的路由機(jī)制。選擇哈希分片還是范圍分片，本質(zhì)上是在“均勻散列”與“范圍局部性”之間做取舍——前者保證寫入熱點(diǎn)分散，后者讓時(shí)間或地域維度的連續(xù)查詢產(chǎn)生更好的分區(qū)剪枝效果。實(shí)踐中，千億級(jí)訂單表幾乎都采用“多級(jí)分區(qū)”：一級(jí) HASH 按 user_id 打散到數(shù)百個(gè)物理分片，避免單分片熱點(diǎn)；二級(jí) RANGE 按 create_time 進(jìn)一步分割，使歷史數(shù)據(jù)清理和范圍掃描只需操作少數(shù)分片。這種級(jí)聯(lián)分區(qū)能把幾十億行的掃描壓到千萬級(jí)以內(nèi)，結(jié)合全局二級(jí)索引，即使按非分區(qū)鍵查詢，也能精確路由到目標(biāo)分片而不是全分片遍歷。

1. 分區(qū)鍵設(shè)計(jì)有哪些技巧？

分區(qū)鍵選錯(cuò)，后果不是“慢一點(diǎn)”，而是全網(wǎng)掃描。一個(gè)經(jīng)典的翻車場(chǎng)景是：物流軌跡表用運(yùn)單號(hào)做 HASH 分區(qū)，結(jié)果運(yùn)營團(tuán)隊(duì)按客戶維度查詢歷史軌跡時(shí)，SQL 被迫遍歷所有分片，P99 延遲從毫秒級(jí)惡化到數(shù)十秒。設(shè)計(jì)分區(qū)鍵的首要原則是貼近最高頻的查詢模式。對(duì)于 C 端業(yè)務(wù)，用戶 ID 幾乎總是最優(yōu)的一級(jí) HASH 鍵；對(duì)于 B 端 SaaS，租戶 ID 是天然的分區(qū)錨點(diǎn)。這里有一個(gè)容易被忽視的細(xì)節(jié)：分區(qū)鍵的值的基數(shù)要足夠高。如果用業(yè)務(wù)狀態(tài)（如“待支付”“已發(fā)貨”）做 HASH 分區(qū)，幾個(gè)值最終只會(huì)落到少數(shù)分片，集群資源利用率極低，熱點(diǎn)問題反而加劇。

另外，分區(qū)鍵需要避免更新操作。如果業(yè)務(wù)會(huì)修改 user_id 或訂單號(hào)，分片路由就會(huì)失效，引發(fā)跨分片數(shù)據(jù)遷移——這在千億行表中是不可接受的。解決方案是在表設(shè)計(jì)階段就將不可變字段作為分區(qū)鍵，必要時(shí)引入一個(gè)冗余的“分片錨點(diǎn)列”。PolarDB-X 支持分區(qū)鍵與主鍵解耦，允許主鍵使用自增 ID，分區(qū)鍵用 user_id，這為設(shè)計(jì)提供了很大彈性。針對(duì)分析型負(fù)載，還可以利用全局二級(jí)索引創(chuàng)建按 gmt_create 排序的索引表，讓 BI 側(cè)的時(shí)間范圍查詢直接命中單一索引分片，繞過主分區(qū)鍵的限制。

2. 在線重分片如何操作？

在線重分片并非“一鍵操作”，而是一個(gè)涉及源端鎖定、數(shù)據(jù)搬遷、校驗(yàn)與切換的工程過程。千億行表直接執(zhí)行 ALTER TABLE 重分片會(huì)引發(fā)長時(shí)間元數(shù)據(jù)鎖，業(yè)務(wù)無法接受。PolarDB-X 提供的在線分片變更功能，通過“影子表+增量同步”模式解決此問題：系統(tǒng)創(chuàng)建一張具有新分區(qū)規(guī)則的空表，然后借助原生 CDC 把舊表的全量和增量數(shù)據(jù)同步到新表，期間舊表讀寫完全不受影響。同步延遲穩(wěn)定在毫秒級(jí)后，進(jìn)入切換窗口——通常在業(yè)務(wù)低峰期的數(shù)秒內(nèi)完成元數(shù)據(jù)替換，并反轉(zhuǎn)同步鏈路，把切換期間到達(dá)的增量補(bǔ)寫回新表。

但重分片的風(fēng)險(xiǎn)不在技術(shù)流程，而在校驗(yàn)和回滾策略。全量數(shù)據(jù)同步完畢后，必須進(jìn)行行數(shù)、主鍵、關(guān)鍵字段 hash 值的多輪校驗(yàn)。如果新分區(qū)鍵的選擇導(dǎo)致數(shù)據(jù)傾斜（例如用城市做 HASH，但北上廣深的數(shù)據(jù)占據(jù) 80%），重分布后的新分片會(huì)出現(xiàn)存儲(chǔ)和負(fù)載不均，需要調(diào)整分片數(shù)或改變分區(qū)策略?；貪L方案同樣重要：切換前保留舊表至少 24 小時(shí)，確保新表出現(xiàn)任何數(shù)據(jù)不一致時(shí)，可以快速切回舊表，同時(shí)反向同步增量數(shù)據(jù)。對(duì)于金融或交易類核心庫，這套操作往往要在沙箱環(huán)境反復(fù)演練，形成從灰度驗(yàn)證到全量切換的 SOP，而不是依賴某個(gè)工具的“自動(dòng)化魔法”。

四、性能優(yōu)化的關(guān)鍵技術(shù)

在千億行規(guī)模下，性能優(yōu)化不再是“加個(gè)索引”或“擴(kuò)個(gè)內(nèi)存”的簡單動(dòng)作，而是一套由并行計(jì)算、索引設(shè)計(jì)和存儲(chǔ)成本控制構(gòu)成的系統(tǒng)工程。這三個(gè)維度互相牽制，單獨(dú)優(yōu)化其中一環(huán)往往難以獲得線性收益，甚至可能引發(fā)新的資源爭搶。下面的實(shí)踐均來自對(duì) PolarDB 公開技術(shù)架構(gòu)和大量業(yè)務(wù)落地案例的提煉，部分判斷基于其分布式版本（PolarDB?X）及計(jì)算存儲(chǔ)分離的內(nèi)核能力。

1. 并行查詢的開啟與調(diào)優(yōu)策略

單機(jī)數(shù)據(jù)庫的并行查詢多以線程池的方式在一個(gè)節(jié)點(diǎn)內(nèi)展開，但面對(duì)千億行事實(shí)表與多張維度表的星型關(guān)聯(lián)，單機(jī)并行度很快撞上內(nèi)存帶寬與 CPU 物理核數(shù)的天花板。PolarDB 的并行框架將算子拆分后分發(fā)到多個(gè)只讀節(jié)點(diǎn)同時(shí)執(zhí)行，再匯聚中間結(jié)果，本質(zhì)上把查詢算力從“一棵樹”變成了“一片森林”。實(shí)測(cè)過的一家物流軌跡團(tuán)隊(duì)，將 max_parallel_degree 從默認(rèn)值調(diào)整為 8 后，針對(duì) 1200 億行軌跡表的 COUNT(DISTINCT) 聚合耗時(shí)從 137 秒壓縮到 19 秒，提速約 7.2 倍；進(jìn)一步上調(diào)至 16，提升幅度收窄至 11 秒，但此時(shí) CPU 利用率已近 85%，對(duì)常規(guī)在線事務(wù)產(chǎn)生可見抖動(dòng)。

關(guān)鍵不是把并行度直接拉滿，而是根據(jù)實(shí)例規(guī)格和負(fù)載特征找準(zhǔn)“甜點(diǎn)區(qū)間”。PolarDB 允許在會(huì)話級(jí)或 SQL 級(jí)通過 hint 單獨(dú)指定并行度，這給了 DBA 精細(xì)控制的裕度。另外需要注意，并行查詢對(duì) I/O 的依賴遠(yuǎn)低于對(duì)內(nèi)存和算力的依賴：因?yàn)楣蚕泶鎯?chǔ)在 PolarFileSystem 上，多個(gè)只讀節(jié)點(diǎn)可以幾乎同步讀取同一份數(shù)據(jù)塊，省去了數(shù)據(jù)重分布的開銷。如果查詢涉及大量非覆蓋索引的回表，即使開啟并行，回表隨機(jī)讀也會(huì)稀釋加速效果——此時(shí)應(yīng)優(yōu)先考慮覆蓋索引或物化中間結(jié)果，而不是繼續(xù)堆并行度。

2. 全局二級(jí)索引設(shè)計(jì)與索引成本陷阱

千億行大表很容易掉進(jìn)“索引越多查詢?cè)娇臁钡闹庇X誤區(qū)。PolarDB?X 支持全局二級(jí)索引（GSI），使得指定索引可以獨(dú)立于主表的分區(qū)鍵進(jìn)行分區(qū)，比如主表按 user_id HASH 分區(qū)，GSI 按 order_time RANGE 分區(qū)，這樣既能保證用戶維度的點(diǎn)查命中單分片，又能支持時(shí)間范圍的批量排序查詢。但 GSI 帶來兩個(gè)切身之痛：一是寫放大，每個(gè) INSERT、UPDATE、DELETE 都需要同步維護(hù) GSI，并通過兩階段提交保證分布式一致性，單行寫入延遲會(huì)從基表操作的 1?2ms 升至 3?5ms；二是存儲(chǔ)膨脹，GSI 本身是一個(gè)完整的 B+ 樹結(jié)構(gòu)，對(duì)于寬表，一個(gè) GSI 的數(shù)據(jù)量可能接近基表的一半，三個(gè) GSI 的存儲(chǔ)總成本可能超過基表本身。

因此，索引設(shè)計(jì)必須在查詢模式與寫入代價(jià)之間做嚴(yán)格取舍。一種被多個(gè)團(tuán)隊(duì)驗(yàn)證過的策略是：只對(duì)那些承載 80% 以上高頻查詢的列組合建立全局索引，其余低頻分析需求用異步物化視圖或只讀實(shí)例的并行查詢解決。同時(shí)，PolarDB 支持將 GSI 建為覆蓋索引，把 SELECT 中需要的列包含在索引葉子節(jié)點(diǎn)，避免回表，這在一張 800 億行的支付流水表中，將商戶維度對(duì)帳查詢的 RT 從 4.2 秒降至 0.3 秒，且對(duì)寫入的影響幾乎無感。另一個(gè)常被忽略的細(xì)節(jié)是分區(qū)對(duì)齊：如果 GSI 的主鍵前綴包含原表的一級(jí)分區(qū)鍵，那么在數(shù)據(jù)搬遷或擴(kuò)容時(shí)，GSI 可以跟隨對(duì)應(yīng)的基表分片一起遷移，不會(huì)產(chǎn)生跨機(jī)的大量數(shù)據(jù) shuffle。

3. 智能壓縮與冷熱分層：成本控制的最后防線

當(dāng)單表數(shù)據(jù)量突破千億，有些業(yè)務(wù)存儲(chǔ)量會(huì)直奔 PB 級(jí)，成本壓力甚至超過性能壓力。PolarDB 的 ZSTD 壓縮算法在典型日志和軌跡場(chǎng)景下可以做到 3?5 倍的壓縮率，而且壓縮和解壓在數(shù)據(jù)塊級(jí)別自動(dòng)完成，對(duì)上層 SQL 透明——查詢引擎讀取頁面時(shí)即時(shí)解壓，寫操作交由后臺(tái)壓縮線程異步處理，不會(huì)拖慢關(guān)鍵路徑。一家 IoT 平臺(tái)對(duì)持續(xù)寫入的 960 億行設(shè)備日志開啟 ZSTD 后，存儲(chǔ)空間從 48TB 縮減到約 13TB，同時(shí)由于頁面壓縮后單個(gè) I/O 讀取的數(shù)據(jù)量減少，范圍掃描的吞吐反而提升了 18%。

比壓縮更具成本杠桿的是冷熱分層。PolarDB 允許將分區(qū)表中的冷分區(qū)（如 30 天前的賬單數(shù)據(jù)）直接從共享存儲(chǔ)遷移至 OSS，這個(gè)遷移動(dòng)作不阻塞讀寫，且遷移后 SQL 仍然可以像訪問普通表一樣查詢這些數(shù)據(jù)，只是 SQL 延遲會(huì)從毫秒級(jí)變?yōu)槊爰?jí)。對(duì)于僅偶爾用于審計(jì)或低頻報(bào)表的歷史數(shù)據(jù)，用幾秒的查詢代價(jià)換 90% 以上的存儲(chǔ)成本削減，是一筆極其合算的賬。關(guān)鍵是建立自動(dòng)化的生命周期策略：按天分區(qū)、超過閾值的分區(qū)自動(dòng)歸檔，再結(jié)合只讀實(shí)例專門承接冷數(shù)據(jù)查詢，主實(shí)例上連冷分區(qū)的統(tǒng)計(jì)信息都不必常駐內(nèi)存，可以將寶貴的 buffer pool 全部留給熱數(shù)據(jù)。這套組合拳下來，千億行訂單表的主實(shí)例活躍數(shù)據(jù)保持在最近 7 天，約 20 億行，節(jié)點(diǎn)規(guī)格無需無限膨脹，整體 TCO 比全閃存全量存儲(chǔ)降低超過 60%。

五、高并發(fā)下的彈性與一致性

當(dāng)單表數(shù)據(jù)量沖上千億行，每天數(shù)十億次寫入持續(xù)涌入，數(shù)據(jù)庫架構(gòu)面臨的已經(jīng)不是“能不能撐住”，而是“能否線性撐住”。傳統(tǒng)的分庫分表中間件方案，把分片邏輯外掛到應(yīng)用層，路由鍵的選擇、跨分片聚合、分布式事務(wù)都需要業(yè)務(wù)代碼深度配合，一旦查詢模式發(fā)生變化，局部重構(gòu)往往演變成全鏈路改造。而云原生架構(gòu)下的透明分布式，正嘗試把這些復(fù)雜性收斂進(jìn)內(nèi)核，用一套統(tǒng)一的 SQL 語義和事務(wù)模型，讓千億級(jí)大表也能獲得接近單機(jī)的高可用和高性能體驗(yàn)。

1. 如何實(shí)現(xiàn)線性擴(kuò)展？

線性擴(kuò)展的前提是把數(shù)據(jù)均勻打散，同時(shí)讓計(jì)算能力能夠隨之水平疊加。PolarDB 分布式版本（PolarDB-X）的做法是將大表按用戶指定的分區(qū)鍵自動(dòng)切分為大量物理分片，每個(gè)分片在存儲(chǔ)層對(duì)應(yīng)獨(dú)立的文件組，計(jì)算節(jié)點(diǎn)只負(fù)責(zé)將 SQL 路由到正確的分片上執(zhí)行。實(shí)際落地的案例中，一張千億行的軌跡表，以運(yùn)單號(hào)的哈希值作為一級(jí)分區(qū)鍵，配合按天創(chuàng)建的 RANGE 二級(jí)分區(qū)，單表物理分片數(shù)量可以達(dá)到上萬。這樣，每個(gè)分片內(nèi)部的行數(shù)被控制在百萬級(jí)，B+ 樹深度從傳統(tǒng)千億表的 7～8 層降低到 3～4 層，主鍵寫入和點(diǎn)查的延遲與普通百萬行小表幾乎無差別。

在吞吐能力上，這種拆分帶來的增益非常直接。該集群從 8 個(gè)計(jì)算節(jié)點(diǎn)擴(kuò)展到 16 個(gè)節(jié)點(diǎn)的過程中，系統(tǒng)實(shí)測(cè)的寫入 TPS 增長了大約 1.9 倍，讀取 QPS 增長約 1.8 倍，基本保持了線性。關(guān)鍵在于路由開銷沒有隨著節(jié)點(diǎn)數(shù)增加而顯著上升——因?yàn)?SQL 的解析與分片路由在計(jì)算節(jié)點(diǎn)本地完成，不經(jīng)過中心化元數(shù)據(jù)服務(wù)，而存儲(chǔ)層共享的 PolarFileSystem 則保證了所有分片的數(shù)據(jù)對(duì)新增節(jié)點(diǎn)立即可見。這使得擴(kuò)容不再需要重新均衡數(shù)據(jù)，只需拉起新的計(jì)算節(jié)點(diǎn)并掛載同一套共享存儲(chǔ)即可在幾分鐘內(nèi)完成，千億行表的重分布難題被徹底繞開。

2. 全局一致性讀與事務(wù)保障

千億行表在拆分后，跨分片的分布式事務(wù)是繞不過去的坎兒。如果繼續(xù)沿用最終一致性讀，支付鏈路就會(huì)暴露出經(jīng)典的“下完單卻查不到訂單”的問題，這在金融、電商高頻場(chǎng)景下是不可接受的。PolarDB-X 的全局一致性讀方案建立在集中式授時(shí)服務(wù)（TSO）和共享存儲(chǔ)的物理復(fù)制之上：所有寫操作在主節(jié)點(diǎn)提交時(shí)獲取全局遞增的時(shí)間戳，Redo 日志通過 PolarFileSystem 的并行分發(fā)機(jī)制，在毫秒級(jí)內(nèi)推送到所有只讀節(jié)點(diǎn)，讀節(jié)點(diǎn)可以依據(jù)數(shù)據(jù)頁上的時(shí)間戳信息，提供截至某全局時(shí)刻的快照讀。

這種做法與傳統(tǒng) Binlog 邏輯復(fù)制不同，它不依賴 SQL 重放，不受大事務(wù)提交卡住復(fù)制通道的影響，因此即便是在一個(gè)大事務(wù)批量歸檔 5 億行歷史數(shù)據(jù)的場(chǎng)景下，只讀節(jié)點(diǎn)的延遲仍保持在 20 毫秒以內(nèi)。全局一致性讀開啟后，一個(gè)用戶在支付成功后的首次刷新，就能通過只讀節(jié)點(diǎn)讀到剛剛提交的訂單狀態(tài)，不會(huì)因?yàn)樽x寫分離而出現(xiàn)任何“消失的訂單”。對(duì)于需要跨越多個(gè)分片做匯總的報(bào)表查詢，同樣可以指定一致性快照時(shí)間，保證所有分片上的數(shù)據(jù)處于同一事務(wù)邊界內(nèi)，避免跨分片不一致帶來的金額對(duì)不平、庫存對(duì)不上的問題。

3. 讀寫鏈路隔離策略

面對(duì)千億行大表，僅靠主實(shí)例單點(diǎn)扛所有負(fù)載顯然不經(jīng)濟(jì)，讀寫分離實(shí)際上是成本與性能的平衡杠桿。PolarDB 的共享存儲(chǔ)架構(gòu)天然支持讀寫分離，一個(gè)主節(jié)點(diǎn)可掛載最多 16 個(gè)只讀實(shí)例，應(yīng)用通過集群地址即可自動(dòng)將讀請(qǐng)求分流到只讀節(jié)點(diǎn)。關(guān)鍵在于，隔離策略需要區(qū)分兩類讀負(fù)載：要求強(qiáng)一致性的在線查詢，指向開啟了全局一致性讀的只讀節(jié)點(diǎn)；而允許少量延遲的離線分析、報(bào)表查詢，則走普通只讀節(jié)點(diǎn)，通過并行查詢進(jìn)一步提升大表掃描效率。

以某個(gè)電商訂單大表為例，TP 類查詢（查訂單詳情、查物流）約占全部讀請(qǐng)求的 80%，它們走兩個(gè)強(qiáng)一致讀只讀節(jié)點(diǎn)，節(jié)點(diǎn)規(guī)格與主實(shí)例基本一致，確保延遲無波動(dòng)；剩余的 AP 查詢（每日經(jīng)營報(bào)表、退款分析）則路由到兩臺(tái)高內(nèi)存、高 CPU 的分析型只讀節(jié)點(diǎn)，通過設(shè)置 max_parallel_degree 為 16，使千億行表的全表掃描耗時(shí)從數(shù)十分鐘壓縮到 3 分鐘以內(nèi)，而這期間主實(shí)例的在線交易延遲完全不受影響。另一個(gè)容易被忽略的細(xì)節(jié)是成本：只讀節(jié)點(diǎn)可以按需彈性伸縮，大促前臨時(shí)彈出高性能只讀節(jié)點(diǎn)應(yīng)對(duì)峰值，大促后釋放，而冷數(shù)據(jù)在存儲(chǔ)層已通過自動(dòng)壓縮和對(duì)象存儲(chǔ)歸檔，存儲(chǔ)成本降到在線高可用存儲(chǔ)的 1/4，整個(gè)方案的總體擁有成本反而低于自建一套同樣承載能力的分布式中間件集群。

六、從規(guī)劃到落地的實(shí)踐建議

1. 遷移前如何評(píng)估成本？

千億級(jí)大表的遷移不能只看數(shù)據(jù)庫本身的單價(jià)，存儲(chǔ)和計(jì)算資源的隱性開銷往往才是大頭。首先要對(duì)現(xiàn)有數(shù)據(jù)量做一次精確摸底：拿出 SHOW TABLE STATUS 里的 Data_length + Index_length，乘上 PolarDB 實(shí)際寫入放大的經(jīng)驗(yàn)系數(shù)（開啟 ZSTD 壓縮后通常在 1:3 到 1:5 之間），就能估算出 PolarFS 上需要掛載的實(shí)際存儲(chǔ)空間。如果業(yè)務(wù)允許冷熱分離，必須把訪問頻率低于某個(gè)閾值的歷史分區(qū)單獨(dú)拎出來核算——將它們放在 OSS 歸檔層，存儲(chǔ)成本可以降到主存儲(chǔ)的 1/10 以下，這決定了整體 TCO 的“水線”在哪里。

計(jì)算側(cè)的成本評(píng)估更依賴 SQL 審計(jì)日志。導(dǎo)出過去 30 天的慢查詢記錄，按掃描行數(shù)和執(zhí)行頻次聚類，標(biāo)記出哪些 SQL 是千億大表全分片掃描、哪些只是命中固定分區(qū)。PolarDB-X 的并行查詢能把全表掃描時(shí)間從小時(shí)級(jí)壓縮到分鐘級(jí)，但會(huì)按 CPU 核數(shù)線性消耗計(jì)算資源；如果這類分析型 SQL 日均執(zhí)行量超過 50 次，就需要額外估算只讀節(jié)點(diǎn)數(shù)量，避免主實(shí)例被拖垮。另一個(gè)容易被忽略的是全局二級(jí)索引（GSI）的寫入成本：每增加一個(gè) GSI，INSERT/UPDATE 的 RT 大約增加 20%~35%，同時(shí)分布式事務(wù)提交次數(shù)會(huì)翻倍，這部分對(duì) PolarDB-X 計(jì)算單元的額外消耗需要直接折算成規(guī)格提升的費(fèi)用。

2. 業(yè)務(wù)改造的常見誤區(qū)

最早期的 “去 O” 浪潮讓很多團(tuán)隊(duì)迷信“分庫分表中間件+應(yīng)用路由”的萬能解，結(jié)果千億大表一上線就踩坑。典型表現(xiàn)是訂單表按 user_id 哈希分片后，運(yùn)營后臺(tái)要按商戶 ID 查所有訂單，只能遍歷全部 128 個(gè)分片做 UNION ALL，再在內(nèi)存里排序分頁，延時(shí)直奔 5 秒以上。透明分布式真正有價(jià)值的地方，是把這種二次維度查詢需求交給全局二級(jí)索引，業(yè)務(wù)代碼依然寫成 WHERE merchant_id = xxx，執(zhí)行計(jì)劃自動(dòng)定位到索引所在的單一分片，效果跟單機(jī)表一樣。凡是告訴你“加個(gè)中間件就能搞定透明分布式”的，最好拿跨分區(qū) count (*) 測(cè)試一下，真相瞬間顯形。

另一個(gè)高頻誤區(qū)是把 RDS 上“先建一堆索引再說”的習(xí)慣照搬到千億級(jí)大表上。一個(gè) 5000 億行的用戶行為表，每多加一個(gè)基于時(shí)間戳的二級(jí)索引，每天的寫入放大就會(huì)帶來額外 2~3TB 的 Redo 日志，并且全局索引的分布式事務(wù)開銷會(huì)讓 TPS 直接下降 15% 左右。正確的做法是回歸查詢模式：用 SQL 審計(jì)工具抓取所有 WHERE 條件組合，取 top 3 高頻過濾字段作為索引候選，優(yōu)先構(gòu)建覆蓋索引，讓查詢不需要回表。至于那些一個(gè)月才跑一次的報(bào)表 SQL，寧可開并行查詢?nèi)咧鞅恚矂e為了它而犧牲全天寫入性能。

3. 監(jiān)控與調(diào)優(yōu)長效方案

千億級(jí)大表上線后最危險(xiǎn)的不是慢，而是“變慢的過程沒人察覺”。需要將慢 SQL 監(jiān)控從閾值告警升級(jí)為趨勢(shì)分析：連續(xù) 7 天全表掃描執(zhí)行次數(shù)上升超過 20%，或者某個(gè)分片的平均查詢時(shí)延突破基線 1.3 倍，就應(yīng)該自動(dòng)拉群通知。PolarDB 的 SQL 洞察可以直接把掃描行數(shù)、分片命中情況、undo 使用量這些指標(biāo)接入自建監(jiān)控面板，對(duì)于突然出現(xiàn)的“索引失效”問題，通過對(duì)比執(zhí)行計(jì)劃的變化，多數(shù)可以在 5 分鐘內(nèi)定位到是統(tǒng)計(jì)信息過期還是 DDL 導(dǎo)致的分區(qū)剪枝失效。

長期調(diào)優(yōu)的核心在于分區(qū)策略的持續(xù)演進(jìn)。某物流企業(yè)的運(yùn)單表最初按城市 HASH 分區(qū)，半年后發(fā)現(xiàn)雙十一期間北京、上海分片成為熱點(diǎn)，其他分片資源閑置。通過級(jí)聯(lián)分區(qū)改造為“城市 HASH + 月份 RANGE”，并在 PolarDB-X 上執(zhí)行 Fast-DDL 秒級(jí)加列后，熱點(diǎn)分片數(shù)從 2 個(gè)擴(kuò)展到 12 個(gè)，寫入吞吐提升了 4.6 倍。這個(gè)案例說明分區(qū)鍵不是一選定終身的，每隔一個(gè)統(tǒng)計(jì)周期（建議按季度），就要根據(jù)最新的業(yè)務(wù)流量分布重新評(píng)估分區(qū)鍵的均衡度。結(jié)合自動(dòng)化歸檔腳本，將低于 3 個(gè)月訪問頻率的 RANGE 分區(qū)直接 truncate 并轉(zhuǎn)入冷存儲(chǔ)，既能保持主表體積不會(huì)無限膨脹，也讓查詢優(yōu)化器的統(tǒng)計(jì)信息永遠(yuǎn)保持在“熱數(shù)據(jù)”范圍，避免執(zhí)行計(jì)劃走偏。