数据库分库分表方案实战案例指南：5大方案+避坑技巧（附真实项目案例）

今天有朋友一起沟通了分库分表的方案，又想到有前同事面试也被问到此问题；还有前阵子帮朋友救火排查系统性能问题，登服务器一看直接懵了——核心业务订单表单表数据飙到2亿多，查一笔3个月前的订单要等3秒往上，后台慢查询告警刷个不停，高峰期还总出现接口超时。朋友急得满头汗，我直接给出结论：“别硬扛了，分库分表赶紧安排上，这是唯一能根治的办法”。

在互联网行业，分库分表早已不是藏在技术文档里的冷门知识，而是应对数据量暴增的常规操作。但我发现不少同行对它的理解只停留在“拆大表为小表”的表层，实际落地时要么选不对策略，要么踩坑踩得怀疑人生——比如拆分后跨表查询难度翻倍，或是数据分布不均，新的性能瓶颈比之前更棘手。

今天这篇文章，我结合多年实操经验，用大白话把分库分表的主流方案讲透。从基础概念到真实项目案例，再到避坑干货，全程不玩虚的、不堆套话，不管你是刚入行的后端新人、负责架构选型的工程师，还是想补全技术栈的伙伴，都能看懂、能用得上。全文超3000字，建议先收藏，避免用到时手忙脚乱。

一、先明确：到底什么时候需要分库分表？

聊具体方案前，先给大家提个醒：不是所有数据库都要拆，盲目拆分只会增加系统复杂度，后期运维能把人折腾坏。

先跟大家捋捋单库单表的局限。数据量在百万级以下时，MySQL这类关系型数据库完全能hold住，查询、插入性能都很稳定。但随着业务增长，数据量突破千万甚至亿级，三个致命问题会陆续出现：

• 查询性能断崖式下跌：MySQL的InnoDB引擎依赖B+树索引，单表数据量超1000万（看主键类型及行格式等）后，B+树层级会增至4-5层，查询时需反复进行磁盘IO，速度自然变慢。这就像一本几百页的书，没目录也能快速找到内容；可一旦厚到几千页，逐页查找的效率会大幅下滑。
• 写入压力突破上限：单库的并发写入能力有瓶颈，MySQL单库每秒最多支持几千次写入，具体还要看硬件配置。遇到电商秒杀、直播带货这类高并发场景，大量写入请求拥堵在单库，轻则超时重试，重则数据丢失，直接影响业务正常运转。
• 运维风险居高不下：单表数据量过大，备份和恢复会成为难题。我曾遇到过单表2亿数据的库，全量备份耗时12小时，万一数据库崩溃，恢复时间根本达不到业务要求，造成的损失难以估量。

分库分表的核心目标，就是通过拆分打破这些局限：将大表拆分为小表、单库拆分为多库，让每个小表、小库的数据量维持在百万级（MySQL最优运行范围），既能提升查询速度，又能分散写入压力，还能降低备份、恢复的运维成本。

这里必须纠正一个误区：分库分表不是“万能解药”。它仅能解决数据量和并发量问题，无法改善SQL本身的优化缺陷。

如果单表只有100万数据，查询慢是因为缺少索引、SQL写法粗糙，优先优化SQL和索引，切勿急于拆分——本末倒置只会让问题更复杂。

二、核心概念扫盲：先分清术语，避免后续沟通混乱

讲具体方案前，先统一术语定义，避免后面聊的时候各说各的。分库分表主要分为两大类：垂直拆分和水平拆分，还有两者结合的混合拆分，咱们逐一拆解说明。

1. 垂直拆分（按字段/业务维度拆分）

垂直拆分包含两种形式：垂直分表和垂直分库。

垂直分表按字段拆分，将一张表的字段拆分到两张表——高频核心字段归到主表，低频使用、体积较大的字段（如text类型富文本、blob类型文件）放入副表。以用户表为例，id、姓名、手机号等核心字段存入user_main表，头像URL、个人简介、注册IP等低频字段存入user_ext表，两张表通过user_id关联，查询详情时再进行联表查询即可。

垂直分库更简单，按业务模块拆分。比如电商系统，将用户、订单、商品、支付相关数据，分别存储到4个独立数据库，各自部署在不同服务器，避免单库承载所有业务压力，同时实现业务隔离。

2. 水平拆分（按数据行拆分）

水平拆分按数据行拆分，将一张表的数据分散到多张结构完全一致的表中，每张表仅存储部分数据。以订单表为例，按时间拆分：2024年订单存入order_2024表，2025年订单存入order_2025表；也可按用户ID拆分：偶数ID存入order_0表，奇数ID存入order_1表。

水平分库则是将水平拆分后的表，进一步分散到不同服务器的数据库中。比如order_0表存入数据库A，order_1表存入数据库B，最大限度分散读写压力。

3. 分片键

无论哪种拆分方式，都需要一个拆分依据，这个依据就是分片键。按用户ID拆分时，用户ID即为分片键；按时间拆分时，创建时间即为分片键。分片键的选择直接决定分库分表效果，后面会专门讲这个高频坑。

4. 分片策略

分片策略是基于分片键将数据分配到对应表/库的规则，常见的有时间范围策略、哈希取模策略、固定枚举值策略，这是水平拆分的核心，后续每个方案都会结合案例详细说明。

三、5大主流分库分表方案：理论+实战案例拆解

下面进入核心内容，我将逐一拆解5大主流方案，每个方案都讲清“核心原理、实战案例、优缺点、适用场景”，帮大家快速匹配自身业务需求。

方案一：垂直拆分（分库+分表）—— 业务模块清晰优先选

1. 核心原理

垂直拆分的核心是按业务边界划分数据，无论分表还是分库，都遵循“业务归属清晰、谁负责谁管理”的原则。垂直分表解决“单表字段过多、大字段拖累查询”的问题；垂直分库解决“单库并发过高、业务耦合紧密”的问题，是分库分表的入门级方案。

2. 实战案例：中型电商垂直分库优化

2020年我为一家中型电商做架构优化，当时平台日活超10万，所有业务数据都集中在一个数据库——用户登录、商品查询、订单创建、支付回调全靠这一个库支撑。高峰期单库CPU负载常年飙到90%+，支付接口动不动就超时，用户付款后看不到订单，投诉量居高不下。

我们第一步实施垂直分库，按业务模块拆分为4个独立数据库，各自部署在专属服务器，同时配置独立读写分离，彻底分散压力：

• 用户库（user_db）：存储用户基础信息、登录凭证、收货地址，承接注册、登录、个人中心查询等接口，读写压力相对平稳。
• 商品库（product_db）：存储商品信息、分类、库存、规格，核心承载商品列表、详情查询及库存变更请求，读请求量远高于写请求。
• 订单库（order_db）：存储订单、订单项、物流信息，订单创建、状态更新等写请求高度集中，是高峰期压力最大的数据库。
• 支付库（pay_db）：存储支付记录、退款记录、账户余额，对接第三方支付接口，对数据一致性要求极高。

分库完成后，单库CPU负载直接压到50%以内，支付超时的糟心事彻底根治。但我们发现商品列表接口仍偏慢，排查后发现是商品表的“商品详情”字段在拖后腿——该字段为text类型，存储富文本内容，查询列表时完全用不上，却要伴随加载，造成资源浪费。

随后我们实施垂直分表，将商品表拆分为product_main（核心字段：id、名称、价格、库存、分类）和product_detail（商品详情、售后说明、规格详情）。查询列表时仅调用product_main表，查看详情时再联查product_detail表，接口响应时间从500ms骤降至150ms，优化效果立竿见影。

以下为该中型电商垂直分库分表大致的架构图：

3. 优缺点分析

• 优点：
• 业务解耦彻底：各业务团队独立管理专属数据库，表结构修改、版本迭代互不干扰，开发效率显著提升
• 查询性能升级：剔除大字段、精简表结构，索引效率大幅提升，核心查询速度明显加快
• 部署弹性强：可根据业务需求按需扩容，比如大促期间为订单库追加服务器，日常优化商品库配置，避免资源浪费
• 缺点：
• 无法解决单表数据激增问题：比如订单库的订单表数据仍会持续增长，后续仍需实施水平拆分
• 跨业务查询复杂：如需查询“用户下单的商品信息”，需跨用户库、订单库、商品库查询，只能在应用层组装数据，开发量和系统复杂度同步增加

4. 适用场景

适合业务模块清晰、耦合度低，且单模块内单表数据量暂未突破千万级的系统，如中型电商、CRM系统、ERP系统。垂直拆分通常作为分库分表的第一步，先解决业务耦合和单库压力，后续根据数据增长情况再推进水平拆分。

方案二：水平拆分之范围分片—— 时间/ID递增场景首选

1. 核心原理

范围分片是水平拆分中最常用、最易理解的策略，核心是按分片键的范围区间分配数据。比如按时间、ID区间拆分，每个区间对应专属表/库，数据按规则精准落入对应区间。

举两个直观例子：订单表按时间拆分，每3个月创建一张表，如order_202401_202403、order_202404_202406；用户表按ID区间拆分，1-100万ID存入user_0表，101万-200万ID存入user_1表，依次类推。区间可固定设置，也可动态调整——当某张表数据量接近1000万时，自动新增区间分片。

2. 实战案例：网约车订单表范围分片优化

2022年我为一家网约车平台优化订单系统，当时订单表单表数据量已突破8亿，三个核心问题让运维团队苦不堪言：用户查询3个月前的订单需等待5秒，高峰期每秒2000+订单写入压垮主库，全量备份一次耗时12小时，日常不敢轻易操作。

结合平台业务特点——订单查询几乎围绕时间维度，且超过3个月的历史订单查询量仅为近期订单的1/10，我们最终确定“时间范围+水平分库分表+历史归档”的优化方案，具体实施如下：

• 分片键：订单创建时间（create_time），精准匹配业务查询场景。
• 分片规则：按月份拆表（每月一张订单表），按季度分库（每库存放3个月的表）。例如2024年Q1（1-3月）的表存入order_db_2024q1库，Q2（4-6月）的表存入order_db_2024q2库，逻辑清晰，便于开发和运维管理。
• 历史数据归档：超过6个月的订单数据，迁移至低成本云数据库（归档库），应用层增加判断逻辑——查询近期数据调用业务库，查询历史数据调用归档库，进一步减轻业务库压力。
• 读写分离兜底：每个业务库配置一主两从架构，写请求路由至主库，订单查询、数据统计等读请求分发至从库，进一步分散压力。

优化后效果显著：单表数据量控制在1000万以内，订单创建接口响应时间从300ms降至50ms，用户查询近期订单响应稳定在200ms以内，单库全量备份时间缩短至1小时。

以下为网约车订单表时间范围分片+归档架构图，大致呈现分库分表及数据流转逻辑：

这里分享一个踩坑教训：初期为图省事，计划按半年拆表，结果仅3个月，单表数据量就突破2000万，查询速度再次下滑。后续调整为按月拆分，才将数据量控制在合理范围。因此，范围区间大小需结合业务增长速度设定，宁小勿大，后期调整成本极高。

3. 优缺点分析

• 优点：
• 查询效率拉满：按分片键范围查询（如查询某月订单），可直接定位目标分片，无需跨表跨库，速度极快
• 易理解好维护：数据分布规律清晰，开发人员可快速定位数据存储位置，运维备份、问题排查更高效
• 支持动态扩容：新增分片无需迁移历史数据，如新增2024年7月订单表，直接创建即可，对业务无影响
• 归档便捷：按时间拆分场景下，旧数据可直接迁移至归档库，操作简单且能降低存储成本
• 缺点：
• 热点分片问题突出：如网约车平台，当前月份订单表为绝对热点，所有新订单均写入该表，压力高度集中；而旧月份表几乎无写入请求，造成资源浪费
• 跨范围查询低效：如需查询2024年2-4月订单，需跨Q1、Q2两个库、3张表，只能在应用层组装数据，效率偏低

4. 适用场景

适合分片键具备明显范围属性，且业务查询集中在近期数据的场景，如订单表、日志表、流水表、账单表。这类场景的核心特征是“时间越近，数据访问频率越高”，完美适配范围分片+历史归档模式。

方案三：水平拆分之哈希分片—— 需均匀分布数据选这个

1. 核心原理

哈希分片的核心是通过哈希计算分配数据：对分片键进行哈希处理（如取模运算），根据计算结果将数据分配至对应分片。例如分片键为用户ID，设置4个分片表（user_0至user_3），分配规则为“user_id % 4”，计算结果为0存入user_0表，结果为1存入user_1表，以此类推。

哈希分片分为两种：普通哈希（取模）和一致性哈希。普通哈希实现简单，但扩容风险极高——如从4个分片扩容至8个，大部分数据的存储位置会发生变化，需全量迁移数据，可能导致业务停服；一致性哈希通过环形哈希空间分配数据，扩容时仅需迁移少量数据，可实现平滑扩容，适合业务高速增长场景。

2. 实战案例：社交APP用户表哈希分片落地

我曾对接过一款社交APP，用户量突破5000万，用户表单表数据量达3亿+，核心问题十分典型：用户信息查询缓慢、动态写入并发量高，且用户查询无明显规律——新老用户查询频率相近，范围分片完全不适用。最终我们采用“一致性哈希+水平分库分表”方案，彻底解决了问题。

具体实施细节如下：

• 分片键：用户ID（user_id，通过雪花算法生成，递增但无明显范围规律），可精准定位用户数据。
• 分片规则：采用一致性哈希算法，将用户ID哈希后映射至环形哈希空间，再将空间划分为16个分片（8个数据库，每个库包含2张表），每个分片对应环形空间的一个区间。
• 扩容策略：设置数据量阈值——当某分片数据量超过800万，自动新增分片，此时仅需迁移该分片在环形空间上的一半数据至新分片，无需全量迁移，对业务影响极小。
• 缓存协同兜底：将用户核心信息（姓名、头像、在线状态）存入Redis，减少数据库查询压力；用户动态、评论等数据直接写入对应分片表。

优化后效果超出预期：每个分片数据量控制在500-800万之间，用户信息查询响应时间从400ms降至80ms，动态写入并发量从每秒1000+提升至3000+，后续两次扩容均未停服，数据迁移量控制在10%以内，业务几乎无感知。

这里提醒大家：若业务增长迅速、需频繁扩容，切勿使用普通哈希，务必选择一致性哈希。我曾见过一个采用普通哈希的项目，扩容时全量迁移数据导致业务停服4小时，被客户投诉至总部，教训十分深刻。

以下为头部电商混合拆分整体架构图，较完整呈现“垂直分库+水平分片+中间件支撑”全链路设计：

3. 优缺点分析

• 优点：
• 数据分布均匀：可有效规避热点分片问题，各分片读写压力相近，服务器资源利用率高
• 精准查询高效：按分片键精准查询（如查询单个用户信息），可直接定位至目标分片，无需跨表
• 支持平滑扩容：一致性哈希能大幅减少扩容时的数据迁移量，适合业务高速增长、无法停服的场景
• 缺点：
• 跨分片查询低效：如需查询一批无规律用户的信息，需遍历多个分片，在应用层组装数据，速度较慢
• 实现难度较高：尤其是一致性哈希，需自行封装算法或依赖中间件，相比范围分片更复杂
• 不支持范围查询：如需查询用户ID 100万-200万的用户，只能遍历所有分片，实用性极低

4. 适用场景

适合分片键无明显范围属性，业务查询以分片键精准查询为主，且需实现数据均匀分布、规避热点的场景，如用户表、账号表、设备表、会员表。

方案四：水平拆分之列表分片—— 按固定枚举值拆分用这个

1. 核心原理

列表分片是按分片键的固定枚举值分配数据，如按地区、业务类型、用户等级拆分。每个枚举值（或一组枚举值）对应一个分片，数据根据分片键的具体值落入对应分片。

举个例子：电商订单表按地区拆分，北京、天津、河北订单存入order_north表，上海、江苏、浙江订单存入order_east表，广东、广西、福建订单存入order_south表；也可按订单状态拆分，将待支付、已支付、已取消订单分别存入不同表中。

2. 实战案例：本地生活平台商户表列表分片

有一款本地生活平台（类似美团、饿了么），主打餐饮外卖业务，商户量超10万，商户表单表数据量达800万+，核心需求是“按城市维度管理商户，保障同城商户查询速度”。结合业务需求，我们采用“列表分片+垂直分库”方案，实现了精准优化。

具体实施如下：

• 分片键：商户所在城市ID（city_id，固定枚举值，每个城市对应唯一ID）
• 分片规则：按城市级别拆分，规避数据分布不均问题。一线城市（北上广深）各单独创建一张表，存入一线城市专属库；新一线、二线城市按区域分组（华东、华南、华北），每组对应一张表，存入二线城市库；三线及以下城市合并为一张表，存入下沉市场库
• 业务适配：用户下单时，先根据收货地址确定城市ID，再定位至对应分片表查询商户；商户管理后台按城市维度操作，直接对接对应分片表，运维管理更便捷

该方案完美贴合业务需求：同城商户查询无需跨分片，速度极快；且按城市隔离数据，某城市开展促销活动时，仅影响对应分片表，不会波及其他城市。但缺点也较为明显：北京、上海等一线城市商户数量多，后期单表数据量可能超标，需进一步二次拆分（如按区域拆分为北京东、北京西表）。

3. 优缺点分析

• 优点：
• 贴合业务场景：按枚举值拆分，精准匹配业务查询需求，无需跨分片查询
• 业务隔离性好：不同枚举值对应的数据独立存储，运维管理、故障排查更高效，且能避免业务间相互影响
• 实现简单：无需复杂哈希计算，开发和维护成本低，新手也能快速上手
• 缺点：
• 数据分布不均：热门枚举值（如一线城市）对应分片数据量过大，冷门枚举值（如小众城市）分片数据量过小，造成资源浪费
• 扩展性较差：新增枚举值（如新增城市、新增业务类型）时，需手动新增分片、调整规则，灵活性不足

4. 适用场景

适合分片键为固定枚举值，且业务查询以枚举值维度为主的场景，如商户表（按城市）、订单表（按业务类型）、用户表（按用户等级）、物流表（按区域）。

方案五：混合拆分（垂直+水平）—— 超大规模业务必选

1. 核心原理

混合拆分是“先垂直拆分、后水平拆分”的组合策略，结合两种拆分方式的优势，应对超大规模数据和高并发场景。核心逻辑是：先按业务模块垂直分库，将大系统拆分为独立小模块；再针对各模块中数据量过大的表，结合业务特点实施水平拆分，最大化分散压力。

2. 实战案例：头部电商混合拆分架构

国内某头部电商平台（日活超1亿），核心业务系统采用的就是混合拆分方案，可支撑亿级数据和百万级并发，具体架构如下，供大家参考：

第一阶段：垂直分库：

按业务拆分为用户、商品、订单、支付、物流5大中心库，各中心库独立部署，实现业务解耦和单库压力分散。

第二阶段：针对性水平拆分：

• 订单库：采用“时间范围+用户ID哈希”混合策略，先按时间拆分为年度表，再按用户ID哈希拆分片，既解决订单量过大问题，又缓解热点用户压力。
• 商品库：先按商品分类（列表分片）拆表，再按商品ID哈希拆分片，兼顾分类查询和精准查询效率。
• 用户库：按用户ID哈希拆分片，同时对用户表实施垂直分表（核心信息+扩展信息），进一步提升查询速度。
• 中间件支撑：通过Sharding-JDBC封装分片规则，应用层无需感知分片逻辑；借助MyCat作为数据库代理，实现读写分离、负载均衡和故障转移，降低运维压力。
• 存储分层兜底：热点数据（商品详情、用户信息）存入Redis，高频历史订单存入MongoDB，超低频归档数据存入HDFS，按数据访问频率分配存储资源，控制成本。

这种混合拆分方案能最大化发挥垂直和水平拆分的优势，支撑超大规模业务，但系统复杂度也大幅提升——需专业架构团队设计，开发、测试、运维成本极高，小团队难以承载。

3. 优缺点分析

• 优点：
• 扩展性极强：可应对亿级数据、百万级并发，支撑业务持续增长，几乎无上限
• 灵活性高：可针对不同业务特点，选择最优水平拆分策略，兼顾查询效率和数据分布均衡性
• 容错性好：单个分片故障仅影响对应业务的部分数据，不会导致整个系统瘫痪
• 缺点：
• 复杂度极高：开发、测试、运维均需专业团队支撑，小公司或业务初期完全无需考虑
• 跨分片问题突出：跨分片查询、分布式事务处理难度大，需依赖中间件和业务适配，且会产生性能损耗
• 问题排查困难：出现性能问题时，需逐一分片、中间件、缓存排查，定位问题耗时久

4. 适用场景

适合超大规模业务、数据量达亿级以上、并发量极高的场景，如头部电商、大型社交平台、金融支付系统。这类场景通常具备充足的技术和运维资源，可应对混合拆分带来的高复杂度。

四、分库分表必用中间件：按业务需求精准选型

手动编码实现分库分表逻辑，不仅开发成本高，还易出现bug，实际落地时务必选用成熟中间件。下面为大家推荐4款主流中间件，各有优劣，可结合业务需求选择：

1. Sharding-JDBC

最常用的轻量级中间件，采用客户端模式——嵌入应用程序运行，无需单独部署。支持垂直拆分、水平拆分（范围、哈希、列表），兼容MySQL、PostgreSQL，同时支持分布式事务。

优点：轻量高效，无额外部署成本，配置灵活

缺点：需在应用层集成，对开发有一定侵入性，集群扩展时需同步配置。适合中小规模业务、对性能要求较高的场景

2. MyCat

基于Proxy模式的中间件，需单独部署服务器，应用层通过MyCat访问数据库，对应用层完全无侵入。功能全面，支持分库分表、读写分离、负载均衡、故障转移，兼容多种数据库。

优点：功能完备、对应用透明，运维便捷

缺点：多一层代理转发，性能略逊于Sharding-JDBC，部署和配置复杂度更高。适合大规模业务、注重运维便捷性的场景

3. ShardingSphere-Proxy

Sharding-JDBC的Proxy版本，同样采用Proxy模式，支持分库分表、读写分离、分布式事务，兼容MySQL、PostgreSQL，且支持多语言接入（Java、Python、Go等）。

优点：对应用无侵入、支持多语言开发，集群扩展便捷

缺点：性能略低于Sharding-JDBC。适合多语言开发、需大规模集群部署的场景。

4. OceanBase

阿里开源的分布式数据库，原生具备分库分表能力，无需额外部署中间件。支持水平、垂直拆分，兼容MySQL语法，可实现高可用和分布式事务，适合超大规模业务。

优点：原生分布式架构、性能强劲、容错性好

缺点：部署和维护复杂，学习成本高，小团队难以驾驭。适合头部企业、超大规模数据场景

五、避坑指南：5个高频坑千万别踩！（实战教训）

分库分表看似简单，实际落地时坑点极多。结合我多年踩坑经验，总结5个高频坑，帮大家避开不必要的麻烦：

1. 分片键选择失误（最致命坑）

分片键是分库分表的核心，选不对后续全白费。比如订单表用用户ID做分片键，查询某时间段订单时需跨所有分片；用户表用注册时间做分片键，新用户会集中写入一个分片，形成热点。

避坑小贴士：优先选择“查询频率高、可精准定位分片”的字段作为分片键，订单表选创建时间、用户表选用户ID，基本不会出错；避开无规律、查询频率低的字段。

2. 分片粒度不合理（过大或过小）

分片粒度太大（单表数据量2000万+），相当于没拆分，性能提升不明显；粒度太小（单表数据量10万以下），分片数量过多，管理复杂且跨分片查询频繁。

避坑小贴士：MySQL单表数据量控制在500万-1000万之间，结合业务增长速度调整，宁小勿大，后期合并分片比拆分更简单。

3. 忽视跨分片事务问题

分库分表后，跨分片事务（如下单时扣减余额、减少库存、创建订单）无法通过普通本地事务保证一致性，易出现数据不一致问题。

避坑小贴士：优先通过业务设计，将事务控制在单个分片内；确需跨分片时，采用Seata、Sharding-JDBC的分布式事务方案，同时接受一定性能损耗。

4. 遗漏读写分离与缓存配合

很多人只做分库分表，却忽略读写分离和缓存配置，所有请求都指向主库，主库压力依然巨大，性能提升有限。

避坑小贴士：分库分表必须搭配读写分离（主库写、从库读）和Redis缓存，将读压力从主库转移，最大化提升系统性能。

5. 扩容未考虑数据迁移影响

普通哈希分片扩容时，会导致大量数据迁移，可能迫使业务停服。很多人初期未规划扩容方案，后期陷入被动。

避坑小贴士：初期就选用一致性哈希或动态范围分片，支持平滑扩容；扩容操作选在业务低峰期（如凌晨），做好数据迁移监控，避免出现意外。

六、总结：如何选对适合自己的方案？

分库分表没有“最优方案”，只有“最适配业务的方案”。为大家整理了一套选型思路，可直接套用：

• 先判断是否需要拆分：单表数据量低于1000万、并发量较低，优先优化SQL和索引；超过1000万或并发压力大，再考虑拆分
• 先垂直拆分，再水平拆分：先按业务垂直分库，解决业务耦合和单库压力；再针对数据量超标的表，选择合适的水平拆分策略

水平拆分策略选型：

• 查询以时间为主、需归档旧数据 → 范围分片
• 无范围属性、需数据均匀分布 → 哈希分片
• 按固定枚举值查询、需业务隔离 → 列表分片
• 超大规模业务、多场景混合 → 混合分片

中间件选型：

• 中小规模、性能优先 → Sharding-JDBC
• 大规模、运维友好 → MyCat/ShardingSphere-Proxy
• 超大规模 → OceanBase

最后提醒大家：分库分表是一项系统工程，不仅要选对方案，还需结合业务设计、运维保障、团队能力综合考量。建议初期小步快跑，先在非核心业务试点，积累经验后再推广至核心业务，避免出现重大问题。

如果大家在分库分表落地过程中遇到具体问题，欢迎在评论区留言，我会逐一回复、共同探讨。也可以关注我的微信公众号“数据库干货铺”深入探讨。

觉得这篇文章有用的话，别忘了点赞、收藏、转发给身边的技术伙伴，感谢支持！