MySQL：ShardingSphere-JDBC配Druid时poolPreparedStatements=true让分库分表全军覆没，这个参数到底为什么和分片路由冲突？

摘要与问题定位

在分库分表架构中，ShardingSphere-JDBC 以客户端代理形态接管 SQL 解析、路由与改写，而 Druid 作为底层连接池负责物理连接的创建、复用与语句缓存。二者叠加时，一个常见配置 poolPreparedStatements=true 往往被当作“提升性能”的默认动作写入生产配置，却在部分场景下导致分片路由结果与预期严重偏离，表现为查询落到错误分片、跨分片聚合结果异常，甚至出现“看似全表扫描”的行为。

本文的主线是：预编译语句缓存的“键”与分片路由的“上下文”之间存在粒度不匹配。Druid 的语句缓存以物理连接为作用域、以 SQL 文本（或等价标识）为键；而 ShardingSphere 的路由决策发生在逻辑 SQL 层，且同一逻辑 SQL 在不同分片键取值下会改写为不同物理 SQL。当缓存把“某条物理 SQL 的预编译句柄”错误地复用于另一条逻辑语义不同的请求时，路由与执行之间就出现了语义裂缝。本文将从机制、复现路径、数据验证与治理方案四个层面展开，并给出可操作的参数治理清单。

目录

一、背景与问题定义：连接池与分片中间件的职责边界

1.1 两层抽象的叠加

ShardingSphere-JDBC 的核心职责是逻辑 SQL 到物理 SQL 的转换：解析 SQL 语法树、提取分片键、计算路由目标、改写表名与 SQL 结构、归并结果集。Druid 的职责是物理连接的池化管理：维护连接生命周期、执行语句、缓存预编译句柄。两者在 JDBC 规范下通过 Connection 与 PreparedStatement 接口交互，但各自对“语句”的理解并不一致。

从 JDBC 规范看，PreparedStatement 绑定在创建它的 Connection 上，其语义是“一条已预编译的 SQL 模板 + 一组参数”。Druid 的 poolPreparedStatements 通过 PSCache 在物理连接维度缓存这些句柄，键通常是 SQL 文本的哈希或字符串。问题在于：ShardingSphere 在逻辑层生成的物理 SQL 文本，可能因分片键取值不同而不同；而 Druid 的缓存键若只取“改写前的逻辑 SQL”或“改写后但未携带路由上下文的文本”，就会产生键碰撞。

1.2 问题的典型表征

在真实工单与社区讨论中，该问题的表征往往不是直接报错，而是结果集的静默偏差：同一逻辑查询在分片键不同取值下返回了错误分片的数据；或跨分片查询在归并阶段出现重复行、缺失行。由于没有异常抛出，监控上只表现为“慢查询增多”或“结果对账不一致”，排查成本极高。本文评述：这类“无异常错误”恰恰是分布式数据访问层最危险的故障形态，因为它绕过了常规的异常告警链路。

关键判断：如果分片路由本身正确，但执行层复用了错误的预编译句柄，那么“路由日志”与“实际执行 SQL”会出现不一致。这一不一致是定位本问题的第一现场证据。

二、原理剖析：预编译缓存键、逻辑SQL与物理路由的三方错配

2.1 缓存键的粒度问题

Druid 的 PSCache 在连接维度维护一个映射结构，键为 SQL 字符串，值为 PreparedStatement 句柄。当 ShardingSphere 将逻辑 SQL SELECT * FROM t_order WHERE user_id = ? 改写为物理 SQL SELECT * FROM t_order_0 WHERE user_id = ? 时，物理 SQL 文本已包含分片后缀，理论上键不会碰撞。但若改写发生在参数绑定之后，或某些版本中物理 SQL 的生成依赖执行时的路由结果，而缓存键在改写前就已确定，则存在时序窗口。

更隐蔽的情况是：当分片算法为“范围分片”或“哈希取模”时，同一逻辑 SQL 可能路由到多个物理表，ShardingSphere 会生成多条物理 SQL 并归并结果。若 Druid 缓存以逻辑 SQL 为键，则不同分片键取值对应的物理 SQL 集合不同，却共享同一缓存槽位，导致句柄复用跨越了路由边界。笔者认为，这本质上是“缓存键的语义粒度”与“路由决策的语义粒度”不匹配：缓存键应唯一标识一次物理执行，而非一次逻辑请求。

2.2 路由上下文的生命周期

ShardingSphere 的路由上下文（RouteContext）在一次逻辑请求内有效，包含分片键值、路由目标、改写后的 SQL 集合。Druid 的连接复用则跨越多个逻辑请求：一个物理连接可能先后服务不同分片键的请求。当 poolPreparedStatements=true 时，连接归还池中，其 PSCache 仍保留句柄；下一次请求若命中相同键，直接复用句柄，但该句柄绑定的物理 SQL 可能对应上一次的路由结果。本文评述：这不是简单的“缓存污染”，而是路由上下文与连接生命周期解耦后的语义泄漏。

// 伪代码：错配发生的时序
// 请求A：user_id=1001 -> 路由到 t_order_0
logicalSQL = "SELECT * FROM t_order WHERE user_id = ?"
physicalSQL_A = "SELECT * FROM t_order_0 WHERE user_id = ?"
ps_A = connection.prepareStatement(physicalSQL_A)  // 缓存键=physicalSQL_A

// 请求B：user_id=2002 -> 应路由到 t_order_1
physicalSQL_B = "SELECT * FROM t_order_1 WHERE user_id = ?"
// 若缓存键误用 logicalSQL 或改写前文本，则命中 ps_A
// 执行 ps_A 实际查询 t_order_0，路由结果被覆盖

2.3 与 MySQL 服务端预编译的交互

MySQL 的 useServerPrepStmts 与客户端预编译是另一层变量。当 useServerPrepStmts=true 时，服务端维护语句句柄，客户端缓存的是服务端语句 ID。ShardingSphere 的物理 SQL 改写若发生在客户端预编译之后，服务端句柄与物理 SQL 的对应关系同样可能错位。公开资料中，MySQL Connector/J 文档明确指出服务端预编译对动态 SQL 的收益有限，且会增加服务端资源占用（MySQL 8.0 Reference Manual, 2023）。本文评述：在分片场景下，服务端预编译的“语句复用”假设与物理 SQL 的动态性天然冲突，应优先关闭。

三、复现与验证：可观测指标与最小复现路径

3.1 最小复现环境

建议在隔离环境搭建两库四表：ds_0.t_order_0/1 与 ds_1.t_order_0/1，分片键 user_id 取模。配置 Druid 的 poolPreparedStatements=true 与 maxPoolPreparedStatementPerConnectionSize=50，ShardingSphere 版本建议 5.4.x 与 5.5.x 各测一轮。通过交替执行 user_id=1001 与 user_id=2002 的查询，观察返回行数与实际分片数据是否一致。

验证指标包括：ShardingSphere 的 SQLRoute 日志中的物理 SQL、Druid 的 PSCache 命中统计、MySQL 的 performance_schema.prepared_statements_instances。三者交叉比对可定位错配点。下表为模拟数据（基于两库四表、10 万行测试集，模拟数据，仅用于说明趋势）：

上表说明：命中率提升与延迟下降是真实收益，但收益的前提是缓存键必须携带完整的物理执行语义。本文评述：性能优化不能以牺牲语义正确性为代价，任何缓存键的设计都应满足“同键同执行计划”的不变式。

3.2 可观测性埋点

建议在应用侧对每次逻辑请求记录三元组：(逻辑SQL, 分片键值, 物理SQL列表)，并与 Druid 的 PSCache 访问日志做关联。若同一物理 SQL 文本在不同分片键下被复用，且返回行数与分片数据不符，即可判定为错配。开源社区中，ShardingSphere 的 SQLShow 与 Druid 的 StatFilter 可提供基础数据，但需自行补齐关联维度。

拓展阅读可参考 ShardingSphere 官方文档的“SQL 路由”章节与 Druid 的“PSCache”配置说明，以及 MySQL 官方手册中关于预处理语句的说明。视频教程方面，可检索社区中关于“ShardingSphere 分片路由原理”的公开分享，结合本文的复现路径做对照实验。

四、工程治理：参数矩阵、监控与灰度操作步骤

4.1 参数治理矩阵

治理的核心原则是：让缓存的作用域与路由的作用域对齐。在 ShardingSphere-JDBC + Druid 组合下，推荐关闭 poolPreparedStatements，或将其与 useServerPrepStmts=false 配合使用，并确保物理 SQL 文本作为缓存键。下表给出参数矩阵（基于公开文档与社区实践整理，非虚构实验）：

若确需保留预编译缓存以降低解析开销，应选择支持“物理 SQL 为键”的连接池实现，或在 ShardingSphere 侧开启 sql-show 并配合自定义 StatementCache 包装。本文评述：参数治理不是“一刀切关闭”，而是建立“缓存键必须包含路由维度”的工程契约。

4.2 灰度操作步骤

第一步，在预发环境复现并采集基线：记录 poolPreparedStatements=true 下的结果不一致率与延迟。第二步，关闭该参数并观察 P99 延迟变化，若延迟上升在可接受范围（如小于 20%），优先选择正确性。第三步，若延迟不可接受，引入物理 SQL 键缓存方案并做 A/B 对比。第四步，生产灰度按 1%→10%→50% 流量递增，每阶段校验对账任务。第五步，固化配置到配置中心，禁止个人覆盖。

监控侧建议增加三个告警：物理 SQL 与路由日志不一致计数、PSCache 命中率异常波动、分片结果对账差异。对账任务可按分片键抽样，比对逻辑查询结果与各物理分片直查结果的并集。本文评述：对账是发现“静默错误”的最后一道防线，应作为分片架构的标配而非可选项。

五、对比与局限：不同连接池与中间件组合的边界条件

5.1 与其他连接池的对比

HikariCP 默认不缓存预编译语句，其设计哲学是“连接池只做连接管理”，因此与 ShardingSphere 组合时天然规避了本问题。但 HikariCP 在高并发短查询场景下可能因缺少语句缓存而增加解析开销。本文评述：这体现了“职责单一”与“性能优化”之间的权衡，分片架构下应优先保证语义正确。Druid 的优势在于监控与防火墙能力，若团队依赖其 StatFilter，可通过关闭 PSCache 保留其他能力。

5.2 局限与未解问题

本文的分析基于公开文档与可复现的配置组合，未覆盖所有 ShardingSphere 小版本与 Druid 版本的排列。部分版本可能在改写阶段已保证物理 SQL 键的唯一性，从而不触发本问题；读者应以自身版本的路由日志为准。此外，分布式事务场景下连接与语句的生命周期更复杂，预编译缓存的语义边界仍需进一步研究。笔者认为，长期方向是中间件层提供“执行计划缓存”而非“语句文本缓存”，以执行计划为键才能从根本上对齐路由语义。

六、结论与展望

回到标题的问题：poolPreparedStatements=true 之所以与分片路由冲突，根因不在参数本身，而在于缓存键的语义粒度未能覆盖路由上下文。当缓存以逻辑 SQL 或改写前文本为键时，不同分片键的请求共享了同一预编译句柄，执行层绕过了路由层的决策结果。治理路径清晰：分片场景默认关闭该参数，或以物理 SQL 为键重建缓存契约，并配套对账与告警。

展望未来，随着分片中间件向“执行计划缓存”演进，以及 MySQL 服务端对动态 SQL 预编译的持续优化，这一冲突有望在架构层被消解。但在当下，工程团队应把“缓存键与路由语义对齐”写入架构评审清单，避免性能优化成为正确性的隐性代价。

主要参考文献

文章声明