1. 數(shù)據(jù)庫(kù)分庫(kù)分表從理論到實(shí)戰(zhàn)的全方位解析作為經(jīng)歷過(guò)多個(gè)億級(jí)用戶(hù)系統(tǒng)的架構(gòu)師我深刻理解當(dāng)數(shù)據(jù)量突破單機(jī)數(shù)據(jù)庫(kù)承載能力時(shí)的痛苦。記得有一次凌晨三點(diǎn)我們的訂單數(shù)據(jù)庫(kù)因?yàn)閱伪頂?shù)據(jù)量超過(guò)2億條導(dǎo)致核心交易接口響應(yīng)時(shí)間從200ms飆升到8秒整個(gè)技術(shù)團(tuán)隊(duì)被迫通宵緊急擴(kuò)容。正是這次事故讓我意識(shí)到分庫(kù)分表不是可選項(xiàng)而是高并發(fā)系統(tǒng)發(fā)展到一定階段的必選項(xiàng)。2. 為什么需要分庫(kù)分表2.1 單機(jī)數(shù)據(jù)庫(kù)的性能瓶頸當(dāng)數(shù)據(jù)量達(dá)到千萬(wàn)級(jí)甚至億級(jí)時(shí)單機(jī)數(shù)據(jù)庫(kù)會(huì)面臨四大核心問(wèn)題查詢(xún)性能斷崖式下跌以MySQL的InnoDB引擎為例當(dāng)單表數(shù)據(jù)超過(guò)500萬(wàn)行后即使有索引查詢(xún)延遲也會(huì)顯著增加。這是因?yàn)锽樹(shù)索引的層級(jí)會(huì)隨著數(shù)據(jù)量增長(zhǎng)而加深通常數(shù)據(jù)量500萬(wàn)B樹(shù)3層數(shù)據(jù)量5000萬(wàn)B樹(shù)4層數(shù)據(jù)量5億B樹(shù)5層 每增加一層就意味著多一次磁盤(pán)I/O性能自然下降。索引效率降低我曾經(jīng)處理過(guò)一個(gè)案例某用戶(hù)表有3億數(shù)據(jù)雖然建立了手機(jī)號(hào)的唯一索引但由于索引樹(shù)過(guò)高簡(jiǎn)單的SELECT * FROM users WHERE mobile13800138000查詢(xún)也需要300ms這在業(yè)務(wù)高峰期是完全不可接受的。連接數(shù)成為瓶頸MySQL默認(rèn)的最大連接數(shù)是1515.7版本在高并發(fā)場(chǎng)景下很容易被打滿(mǎn)。雖然可以通過(guò)參數(shù)調(diào)整但單機(jī)連接數(shù)超過(guò)1000后上下文切換的開(kāi)銷(xiāo)會(huì)顯著增加CPU負(fù)載。存儲(chǔ)空間限制即使使用SSD單塊磁盤(pán)的容量和IOPS也是有限的。我們?cè)?jīng)有個(gè)日志表每月增長(zhǎng)1TB不到半年就把服務(wù)器磁盤(pán)撐爆了。實(shí)戰(zhàn)經(jīng)驗(yàn)不要等到系統(tǒng)報(bào)警才考慮分庫(kù)分表。建議單表數(shù)據(jù)量達(dá)到以下閾值時(shí)開(kāi)始規(guī)劃OLTP業(yè)務(wù)表500萬(wàn)行日志類(lèi)表2000萬(wàn)行配置類(lèi)表可適當(dāng)放寬到1000萬(wàn)行3. 分庫(kù)分表的核心策略3.1 垂直拆分按業(yè)務(wù)維度切分垂直拆分是最容易理解的拆分方式它遵循專(zhuān)業(yè)的人做專(zhuān)業(yè)的事原則。以電商系統(tǒng)為例拆分前單一數(shù)據(jù)庫(kù)(ecommerce_db) ├── users ├── orders ├── products ├── payments └── logistics拆分后用戶(hù)庫(kù)(user_db) └── users 訂單庫(kù)(order_db) └── orders 商品庫(kù)(product_db) └── products實(shí)施要點(diǎn)拆分后各庫(kù)應(yīng)部署在不同物理服務(wù)器上避免共享資源需要重構(gòu)事務(wù)代碼跨庫(kù)事務(wù)要改為分布式事務(wù)公共配置數(shù)據(jù)如地區(qū)編碼需要同步或冗余踩坑記錄我們?cè)?jīng)在拆分后將用戶(hù)庫(kù)和訂單庫(kù)放在同一臺(tái)物理機(jī)結(jié)果高峰期兩個(gè)業(yè)務(wù)互相影響。后來(lái)發(fā)現(xiàn)即使做了容器隔離底層磁盤(pán)IO仍然是共享的。3.2 水平拆分按數(shù)據(jù)規(guī)則切分水平拆分是解決單表數(shù)據(jù)過(guò)大的終極方案。常見(jiàn)的分片算法包括3.2.1 哈希取模法-- 按user_id分4個(gè)表 SELECT * FROM users_${user_id % 4} WHERE user_id 12345優(yōu)點(diǎn)數(shù)據(jù)分布均勻缺點(diǎn)擴(kuò)容困難需要遷移數(shù)據(jù)3.2.2 范圍分片-- 按創(chuàng)建時(shí)間分表 SELECT * FROM orders_2023 WHERE created_at BETWEEN 2023-01-01 AND 2023-12-31優(yōu)點(diǎn)易于擴(kuò)容冷熱數(shù)據(jù)分離方便缺點(diǎn)可能產(chǎn)生熱點(diǎn)問(wèn)題3.2.3 一致性哈希使用虛擬節(jié)點(diǎn)解決擴(kuò)容問(wèn)題適合需要頻繁擴(kuò)容的場(chǎng)景。分片鍵選擇對(duì)比表分片鍵類(lèi)型適用場(chǎng)景優(yōu)點(diǎn)缺點(diǎn)用戶(hù)ID用戶(hù)中心系統(tǒng)用戶(hù)數(shù)據(jù)集中大用戶(hù)可能成熱點(diǎn)訂單ID交易系統(tǒng)避免熱點(diǎn)關(guān)聯(lián)查詢(xún)困難時(shí)間日志/統(tǒng)計(jì)系統(tǒng)方便冷熱分離近期數(shù)據(jù)可能成熱點(diǎn)地理區(qū)域本地生活服務(wù)符合業(yè)務(wù)特性跨區(qū)域查詢(xún)性能差實(shí)戰(zhàn)技巧分片鍵的選擇要同時(shí)考慮數(shù)據(jù)的分布均勻性和查詢(xún)模式。我們?cè)?jīng)用訂單ID做分片鍵結(jié)果發(fā)現(xiàn)90%的查詢(xún)都帶有用戶(hù)ID條件導(dǎo)致大量跨庫(kù)查詢(xún)。后來(lái)改為(user_id, order_id)聯(lián)合分片鍵才解決問(wèn)題。4. 分庫(kù)分表中間件深度解析4.1 ShardingSphere實(shí)戰(zhàn)ShardingSphere是目前最流行的分庫(kù)分表中間件支持JDBC和Proxy兩種模式。以下是一個(gè)完整的配置示例# application-sharding.yml spring: shardingsphere: datasource: names: ds0,ds1 ds0: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://db-host-1:3306/order_db?useSSLfalse username: root password: 123456 ds1: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://db-host-2:3306/order_db?useSSLfalse username: root password: 123456 rules: sharding: tables: t_order: actual-data-nodes: ds$-{0..1}.t_order_$-{0..15} database-strategy: standard: sharding-column: user_id precise-algorithm-class-name: com.example.algorithm.UserIdPreciseShardingAlgorithm table-strategy: standard: sharding-column: order_id precise-algorithm-class-name: com.example.algorithm.OrderIdPreciseShardingAlgorithm key-generate-strategy: column: id key-generator-name: snowflake key-generators: snowflake: type: SNOWFLAKE props: worker-id: 123關(guān)鍵配置解析actual-data-nodes定義物理表分布支持Groovy表達(dá)式sharding-column分片字段建議選擇區(qū)分度高且查詢(xún)頻繁的字段precise-algorithm-class-name自定義分片算法實(shí)現(xiàn)PreciseShardingAlgorithm接口性能優(yōu)化在高并發(fā)場(chǎng)景下建議啟用ShardingSphere的SQL緩存功能props: sql-show: true sql-simple: true max.connections.size.per.query: 54.2 MyCat與ShardingSphere對(duì)比特性ShardingSphereMyCat架構(gòu)模式JDBC/ProxyProxy性能損耗低JDBC直連中等網(wǎng)絡(luò)跳轉(zhuǎn)功能完整性完善較完善社區(qū)活躍度高一般學(xué)習(xí)曲線(xiàn)中等簡(jiǎn)單適合場(chǎng)景中大型互聯(lián)網(wǎng)公司傳統(tǒng)企業(yè)選型建議新項(xiàng)目建議直接用ShardingSphere-JDBC老系統(tǒng)改造可以考慮MyCat。5. 跨庫(kù)查詢(xún)解決方案實(shí)戰(zhàn)5.1 禁止跨庫(kù)JOIN的替代方案原始SQLSELECT o.*, u.name FROM orders o JOIN users u ON o.user_id u.id WHERE o.status PAID改造方案先查詢(xún)用戶(hù)ID列表ListLong userIds orderMapper.selectUserIdsByStatus(PAID);批量查詢(xún)用戶(hù)信息MapLong, User userMap userMapper.selectByIds(userIds).stream() .collect(Collectors.toMap(User::getId, Function.identity()));業(yè)務(wù)層組裝數(shù)據(jù)ListOrderDTO dtos orders.stream() .map(o - { OrderDTO dto convert(o); dto.setUserName(userMap.get(o.getUserId()).getName()); return dto; }) .collect(Collectors.toList());5.2 異構(gòu)表設(shè)計(jì)技巧對(duì)于頻繁需要關(guān)聯(lián)查詢(xún)的場(chǎng)景可以采用數(shù)據(jù)冗余方案CREATE TABLE t_order ( id BIGINT PRIMARY KEY, user_id BIGINT NOT NULL, user_name VARCHAR(50) COMMENT 冗余字段, user_level INT COMMENT 冗余字段, amount DECIMAL(10,2), status VARCHAR(20), created_at DATETIME, INDEX idx_user_id (user_id) );同步方案使用觸發(fā)器不推薦影響性能應(yīng)用層雙寫(xiě)需要保證事務(wù)通過(guò)CDC工具如Canal捕獲變更5.3 搜索引擎整合對(duì)于復(fù)雜的多維度查詢(xún)可以引入Elasticsearch// 數(shù)據(jù)同步邏輯 Transactional public void createOrder(Order order) { // 1. 寫(xiě)入數(shù)據(jù)庫(kù) orderMapper.insert(order); // 2. 異步寫(xiě)入ES CompletableFuture.runAsync(() - { esClient.index( IndexRequest.of(ir - ir .index(orders) .id(order.getId().toString()) .document(convertToEsDoc(order)) ) ); }, esThreadPool); }性能數(shù)據(jù)我們某個(gè)系統(tǒng)的訂單查詢(xún)接口從直接查分庫(kù)分表平均120ms改為查ES后P99降到了35ms。6. 分布式ID生成方案對(duì)比6.1 Snowflake算法優(yōu)化原生Snowflake算法存在時(shí)鐘回?fù)軉?wèn)題改進(jìn)方案public class EnhancedSnowflake { private long lastTimestamp -1L; private long sequence 0L; public synchronized long nextId() { long timestamp timeGen(); if (timestamp lastTimestamp) { // 時(shí)鐘回?fù)芴幚?long offset lastTimestamp - timestamp; if (offset 5) { try { wait(offset 1); timestamp timeGen(); } catch (InterruptedException e) { throw new RuntimeException(e); } } else { throw new RuntimeException(Clock moved backwards); } } if (lastTimestamp timestamp) { sequence (sequence 1) sequenceMask; if (sequence 0) { timestamp tilNextMillis(lastTimestamp); } } else { sequence 0L; } lastTimestamp timestamp; return ((timestamp - twepoch) timestampLeftShift) | (datacenterId datacenterIdShift) | (workerId workerIdShift) | sequence; } }6.2 其他ID方案對(duì)比方案優(yōu)點(diǎn)缺點(diǎn)適用場(chǎng)景數(shù)據(jù)庫(kù)自增簡(jiǎn)單可靠有性能瓶頸小規(guī)模系統(tǒng)Redis INCR性能好依賴(lài)Redis需要高QPS生成UUID無(wú)中心化無(wú)序、存儲(chǔ)空間大臨時(shí)數(shù)據(jù)標(biāo)識(shí)Leaf-segment高性能、可擴(kuò)展需要DB支持中大型互聯(lián)網(wǎng)公司7. 分庫(kù)分表后的運(yùn)維挑戰(zhàn)7.1 擴(kuò)容數(shù)據(jù)遷移方案雙寫(xiě)遷移流程上線(xiàn)新分片規(guī)則同時(shí)寫(xiě)新舊庫(kù)后臺(tái)任務(wù)逐步遷移歷史數(shù)據(jù)數(shù)據(jù)校驗(yàn)確保一致性切換讀請(qǐng)求到新庫(kù)下線(xiàn)舊庫(kù)寫(xiě)入// 雙寫(xiě)示例 public void createOrder(Order order) { // 獲取新老分片目標(biāo) String newTarget calculateNewShard(order); String oldTarget calculateOldShard(order); // 開(kāi)啟事務(wù) TransactionTemplate template new TransactionTemplate(transactionManager); template.execute(status - { // 寫(xiě)入新庫(kù) newOrderMapper.insert(newTarget, order); // 寫(xiě)入舊庫(kù) oldOrderMapper.insert(oldTarget, order); return null; }); }7.2 分頁(yè)查詢(xún)優(yōu)化方案深分頁(yè)優(yōu)化方案對(duì)比方案實(shí)現(xiàn)復(fù)雜度性能適用場(chǎng)景游標(biāo)分頁(yè)低優(yōu)有序ID分頁(yè)二次查詢(xún)中良非主鍵排序搜索引擎高優(yōu)復(fù)雜條件分頁(yè)內(nèi)存分頁(yè)低差小數(shù)據(jù)量游標(biāo)分頁(yè)實(shí)現(xiàn)示例-- 第一頁(yè) SELECT * FROM orders WHERE user_id 123 ORDER BY id LIMIT 10; -- 后續(xù)頁(yè)使用上一頁(yè)最后一條記錄的ID SELECT * FROM orders WHERE user_id 123 AND id 上一頁(yè)最后ID ORDER BY id LIMIT 10;8. 分布式事務(wù)解決方案8.1 Seata AT模式實(shí)戰(zhàn)GlobalTransactional public void placeOrder(OrderRequest request) { // 1. 扣減庫(kù)存 productService.reduceStock(request.getProductId(), request.getQuantity()); // 2. 創(chuàng)建訂單 Order order createOrder(request); orderMapper.insert(order); // 3. 扣減余額 accountService.debit(request.getUserId(), order.getAmount()); }AT模式執(zhí)行流程解析SQL生成前后鏡像注冊(cè)分支事務(wù)報(bào)告全局事務(wù)狀態(tài)異步進(jìn)行二階段提交/回滾8.2 TCC模式設(shè)計(jì)要點(diǎn)public interface OrderTccService { TwoPhaseBusinessAction(name createOrder, commitMethod commit, rollbackMethod rollback) boolean tryCreateOrder(Order order); boolean commit(Order order); boolean rollback(Order order); }TCC注意事項(xiàng)空回滾問(wèn)題需要判斷try是否執(zhí)行冪等控制網(wǎng)絡(luò)重試可能導(dǎo)致重復(fù)調(diào)用懸掛問(wèn)題cancel比try先執(zhí)行9. 監(jiān)控與調(diào)優(yōu)實(shí)戰(zhàn)9.1 關(guān)鍵監(jiān)控指標(biāo)# ShardingSphere監(jiān)控指標(biāo)示例 shardingsphere_statement_latency_milliseconds_sum{typeSELECT} 1500 shardingsphere_statement_total{typeINSERT} 12000 shardingsphere_routed_data_sources_total 4 shardingsphere_routed_tables_total 32監(jiān)控大盤(pán)建議分庫(kù)分表路由統(tǒng)計(jì)SQL執(zhí)行耗時(shí)分布分布式事務(wù)成功率連接池使用情況9.2 性能調(diào)優(yōu)案例問(wèn)題現(xiàn)象某系統(tǒng)分庫(kù)分表后查詢(xún)性能反而下降。排查過(guò)程發(fā)現(xiàn)大量IN查詢(xún)跨多個(gè)分片跟蹤SQL日志確認(rèn)分片鍵使用不當(dāng)分析業(yè)務(wù)場(chǎng)景90%查詢(xún)都帶有create_time條件解決方案將分片鍵從user_id改為(create_time, user_id)組合建立月份分表如orders_202301增加本地緩存減少跨分片查詢(xún)優(yōu)化效果平均響應(yīng)時(shí)間從320ms降到85ms數(shù)據(jù)庫(kù)CPU使用率從70%降到35%10. 分庫(kù)分表的最佳實(shí)踐經(jīng)過(guò)多個(gè)項(xiàng)目的實(shí)戰(zhàn)我總結(jié)了以下黃金法則分片鍵選擇三原則查詢(xún)必須帶分片鍵條件數(shù)據(jù)分布均勻避免跨分片查詢(xún)擴(kuò)容預(yù)留空間初始設(shè)計(jì)時(shí)就考慮2-3倍的擴(kuò)容空間比如預(yù)計(jì)3年數(shù)據(jù)量按6年容量設(shè)計(jì)分片數(shù)冷熱據(jù)分離熱數(shù)據(jù)最近3個(gè)月用SSD存儲(chǔ)溫?cái)?shù)據(jù)3-12個(gè)月用普通磁盤(pán)冷數(shù)據(jù)歸檔到對(duì)象存儲(chǔ)避免過(guò)度設(shè)計(jì)單表百萬(wàn)級(jí)不必分表單庫(kù)千萬(wàn)級(jí)不必分庫(kù)能用讀寫(xiě)分離解決的不用分庫(kù)分表工具鏈建設(shè)數(shù)據(jù)遷移工具分片鍵在線(xiàn)修改工具數(shù)據(jù)校驗(yàn)工具最后給個(gè)實(shí)用建議在實(shí)施分庫(kù)分表前先用現(xiàn)有數(shù)據(jù)做全量壓測(cè)模擬分片后的查詢(xún)模式這樣可以提前發(fā)現(xiàn)大部分潛在問(wèn)題。我們?cè)?jīng)用這個(gè)方法避免了上線(xiàn)后的三次重大事故。