当 MySQL 单表数据量达到千万级别后，索引维护、查询性能持续下滑，单库硬件扩容也存在上限。Apache ShardingSphere 作为开源分布式数据库中间件，完整提供分库分表、读写分离、分布式事务、数据加密能力，对应用近乎透明。本文深度拆解其核心引擎：SQL 解析、路由、改写、执行、归并。
SQL 解析 → 路由 → 改写 → 执行 → 归并。一条原始 SQL 从应用层进入，经过五个引擎流水线处理，最终返回归并后的统一结果集。这是 ShardingSphere 的核心心脏。
这是整个框架的入口模块。使用 ANTLR4 语法库构建 MySQL 标准语法解析器，将原始 SQL 文本解析为抽象语法树 AST，提取表名、查询字段、分片键、查询条件、聚合函数、排序信息。
基于解析出的分片条件，结合分片算法，定位 SQL 需要下发到哪些库、哪些表。两种路由模式：精准路由与广播路由。
原始 SQL 中的逻辑表名（t_order），需要改写为真实物理表名（t_order_0、t_order_1）。同时处理分页参数修正、别名统一、字段补全等逻辑。
支持多数据源并行执行 SQL，基于线程池调度；提供连接池管理、超时控制、失败重试，兼容多种数据库连接池（HikariCP、Druid 等）。
多个分片返回独立数据集，中间件统一合并结果。三种归并类型：
limit offset, size 在全分片场景极易出现性能灾难——每个分片都要扫描 offset+size 条记录。大数据场景建议使用游标分页替代偏移分页。
从单库单表 1000 万+ 数据爆满，到多库多表分散存储与查询压力。下方为两种方案的数据库拓扑结构对比。
自动区分读、写 SQL：DML 写操作路由至主库；SELECT 查询负载均衡分发至多个从库。支持主从延迟规避、强制走主库 Hint 语法。
四类高频工程痛点。分库分表不是银弹，落地前必须想清楚这些边界问题。
ShardingSphere 包含两大产品形态。前者是客户端中间件，后者是独立代理服务。选型取决于技术栈与运维诉求。
| 方案 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|
| Sharding-JDBC | 无额外服务、性能高 | 仅 Java 可用 | Java 微服务项目 |
| Sharding-Proxy | 跨语言、统一管控 | 新增一层网络转发 | 多语言混合架构、DBA 统一运维 |
ShardingSphere 通过中间件透明化分片逻辑，让业务代码几乎不需要感知多库多表。但分库分表属于架构侵入性方案，优先考虑业务分拆、冷热数据分离、索引优化，最后再选择分片。
ShardingSphere 通过五大引擎流水线——解析、路由、改写、执行、归并——把分片逻辑透明化，让业务代码几乎不需要感知多库多表的存在。这是它在工程上最大的价值。
但请记住：分库分表是架构侵入性方案。一旦走上这条路，跨分片 Join、分布式事务、扩容迁移、偏移分页等问题会伴随整个系统的生命周期。优先考虑业务分拆、冷热分离、索引优化，把分库分表留到最后。
实施前必须定义好分片键、预估数据增长、规划扩容策略。否则，分片不是解药，而是下一个深坑。