关键在于柔性落地：按业务节奏渐进拆分，策略前置、灰度可控、能力可退；分片键须从业务高频查询路径提炼，如物流系统优先选user_id或create_time；推荐shardingsphere-jdbc渐进集成，proxy用于终态统一治理；分布式事务分级处理，5.x内置xa降低侵入性；扩缩容需预扩容、双写迁移、切流下线三步可逆操作。
ShardingSphere 配合 MySQL 实现超大业务体量的分库分表，关键不在“一步到位”，而在“柔性落地”——即按业务增长节奏渐进拆分，避免一次性重构风险，同时保障数据一致性、查询可用性与运维可持续性。核心是策略前置、灰度可控、能力可退。
分片键与分片策略必须从业务真实查询路径中提炼
不能凭经验拍脑袋选字段。比如物流订单系统日均 800 万单，高频查询是「按用户查订单」和「按时间范围查履约状态」，那分片键就应优先考虑 user_id（哈希取模，保证单用户数据局部性）或 create_time（按月 RANGE 拆分，便于冷热分离）。若强行用订单 ID（Snowflake 生成）做分片键，会导致跨分片 JOIN 和聚合查询无法下推，性能反降。
建议做法：
- 先用 MySQL 的
slow_log + pt-query-digest统计 TOP 20 查询 SQL，提取 WHERE 条件中高频、高选择性的字段； - 验证该字段的数据分布：用
COUNT(DISTINCT)和直方图检查是否倾斜（如 5% 用户占 70% 订单，需加扰动哈希）； - 初期只对单张核心大表（如
t_order）启用分片，其余关联表（如t_order_item）先设为绑定表或广播表，降低复杂度。
ShardingSphere-JDBC 适合渐进式集成，Proxy 更适终态统一治理
新业务或微服务改造推荐用 ShardingSphere-JDBC：以 Jar 包形式嵌入 Spring Boot 应用，配置驱动，无需改 SQL，支持运行时动态加载分片规则。上线时可先开启 sql-show: true 观察路由日志，确认所有写操作都命中预期分片，再逐步放开读流量。
当服务数量超过 20+、语言栈异构（含 Python/Go 调用）、或需要统一审计/熔断/灰度发布时，应切换至 ShardingSphere-Proxy。它作为独立网关，把分片逻辑从应用层剥离，但需注意连接池管理——Proxy 默认最大连接数 1024，高并发场景要调优 maxConnectionsSizePerQuery 和后端 MySQL 的 max_connections 匹配。
分布式事务必须按场景分级处理，不盲目上 Seata
不是所有跨库操作都需要强一致。柔性落地要分三级：
- 无事务场景：如订单创建后发 MQ 更新库存，用本地事务 + 最终一致性，ShardingSphere 不干预；
-
弱一致性场景：如订单支付成功后更新用户积分，可用 ShardingSphere 内置的
XA或Seata AT 模式，但仅限单次调用链路（不跨多跳服务）； - 强一致刚性场景：如金融级资金划账，才启用 Seata TC 集群 + TCC 模式，且必须配合业务补偿接口和人工核对机制。
特别提醒：ShardingSphere 5.x 开始已将 XA 纳入内核，spring.shardingsphere.transaction.type: XA 即可启用，无需额外引入 Seata 客户端，大幅降低侵入性。
扩缩容必须设计成可逆、可验证、低感知的操作流
柔性落地最怕“一拆就卡”。真实生产中推荐三步走：
- 预扩容：新增分片节点（如从 4 库扩到 8 库），但暂不写入数据，仅用于读流量灰度；
-
双写迁移：用 ShardingSphere 提供的
orchestration模块 + 自定义数据同步脚本，将老分片数据按 user_id 哈希重分布到新节点，期间新老路径并行写，通过比对 checksum 校验一致性； -
切流下线：确认新分片读写稳定后，修改分片算法配置（如
sharding-algorithm中的sharding-count），重启应用完成切换，原分片库保留 7 天只读备查。
整个过程无需停机，且任意环节失败可回滚到双写前状态。
