JVM 性能工程与分库分表

• JVM 堆与连接池
• 连接池线程数
• 容量联动规划

分库分表应用会同时持有多个分片的数据源连接池，每个连接池的线程与连接数都占用 JVM 资源（堆内存、线程栈、Socket 缓冲）。堆大小与连接池线程数需联动规划：堆大小决定了可承载的并发缓存、结果集与连接缓冲；连接池线程数决定了并发执行能力。若堆不足以支撑连接池所需的连接数（每个连接有缓冲、结果集驻留），会频繁 GC 或 OOM。规划原则：先估算每个分片连接池的连接数与缓冲，乘以分片数得到总连接内存，再加业务堆需求，设定堆大小与线程数，并留余量。避免"堆小连接多"导致的 GC 压力。

分片数量放大连接池资源，堆与连接池必须联动。连接数×缓冲 + 业务内存 + 余量 = 堆规划。连接池线程数决定并发，堆决定缓存容量，二者需匹配。

• Proxy 线程模型
• Netty 与业务线程
• 吞吐瓶颈

ShardingSphere-Proxy 是基于 Netty 的网络代理，接受客户端连接，把 SQL 转发到后端分片。它采用 Netty 的 IO 线程 + 业务线程池模型：IO 线程处理网络读写，业务线程池执行 SQL 解析、改写、路由与后端执行。吞吐瓶颈可能在：SQL 解析/改写的 CPU 开销、后端分片连接池、业务线程池大小、归并操作的内存。大批量跨分片查询、复杂 SQL 解析、慢 SQL 会占用业务线程。优化需调整业务线程池、合理复用连接、优化 SQL 与缓存解析结果。

Proxy 是"IO 线程 + 业务线程池"模型，瓶颈常在 SQL 解析、后端连接与归并。调优涉及线程池、连接池与解析缓存。

• ShardingSphere 分布式事务
• 数据库原生分布式事务
• 边界与选型

ShardingSphere 提供分布式事务方案（XA 通过 Atomikos，BASE 通过 Seata），在应用层/中间件层协调跨分片事务。数据库原生分布式事务（如 PolarDB 的多写/全局事务）由数据库本身保证跨节点一致性，通过 BCC/全局事务等实现。边界：若数据库原生支持分布式事务（如 PolarDB、TiDB），可把一致性交给数据库，应用更简单；若用普通 MySQL 分片，需 ShardingSphere 的 XA/Seata 协调。选型取决于数据库能力与一致性需求：强一致且数据库原生支持则用原生，否则用 ShardingSphere 的 XA/柔性事务。

边界是"谁协调一致性"：数据库原生分布式事务把一致性下沉到 DB，ShardingSphere 在应用/中间件层协调。选型看数据库能力与一致性需求。

• 事务日志
• 异常回滚
• 可观测性

ShardingSphere 的分布式事务（XA/Seata）在协调过程中产生事务日志，可观测性需关注：事务提交/回滚的协调日志、参与方（分片节点）的提交状态、异常回滚的触发与结果。XA 模式下记录 prepare/commit/rollback 协调日志；Seata AT 模式记录 undo log 与分支事务状态。可观测性手段：接入事务协调日志、监控事务状态（pending/committed/rolled back）、记录回滚原因与耗时、用分布式事务监控（如 XA 事务表、Seata 的 global_lock 表）排查不一致。异常回滚需能定位是哪个分片失败、回滚是否成功。

事务可观测性核心是"协调日志 + 参与方状态 + 回滚结果"。通过日志与监控表定位提交失败的分片与回滚完整性，是对账与排查的基础。

• 逻辑表与真实表
• 分片键
• 分片算法

ShardingSphere 的核心概念：逻辑表是应用视角的逻辑表名（如 t_order），真实表是物理上分散在各分片上的实际表（如 t_order_0、t_order_1）；分片键（sharding key）是决定数据路由到哪个分片的字段（如 order_id）；分片算法（sharding algorithm）根据分片键值计算目标分片（如取模、范围、哈希、复合）。路由时用分片键 + 算法确定库表，无分片键则全路由。这些概念构成分库分表的配置基础，逻辑表屏蔽物理分布，真实表承载数据，分片键与算法决定路由。

逻辑表是"抽象"，真实表是"物理"，分片键是"路由依据"，算法是"路由规则"。四者配合实现透明分片，应用只感知逻辑表。

• XA 强一致
• Atomikos 集成
• 性能损耗

ShardingSphere 的 XA 事务用 Atomikos 作为事务管理器，协调多个分片数据源的 XA 事务：prepare 阶段各分片准备，commit 阶段统一提交，实现强一致（ACID）。性能损耗源于 XA 的两阶段提交开销：prepare/commit 的多次往返、事务日志（redo/undo）的持久化、锁持有时间延长、协调开销。相比单库事务，XA 跨分片通信与日志显著增加延迟与吞吐损耗。因此 XA 适合强一致、低频、对性能不敏感的跨分片事务，高频场景考虑柔性事务或规避跨分片事务。

XA 强一致但性能损耗大（2PC 往返、日志、锁延长）。选型需权衡：强一致优先选 XA，性能敏感优先规避或柔性事务。

• ANTLR SQL 解析
• 解析性能
• 缓存优化

ShardingSphere 用 ANTLR 解析 SQL 生成 AST，再转为逻辑查询计划。解析是 CPU 密集操作，频繁执行会成瓶颈。优化：SQL 解析结果缓存（按 SQL 文本缓存 AST/解析结果），相同 SQL 复用解析；预编译 Statement 减少解析；对高频 SQL 优化解析开销；合理配置解析缓存大小。缓存命中后跳过解析，直接进行路由与改写，显著提升吞吐。性能上需监控解析耗时与缓存命中率，避免缓存失效导致的重复解析。

解析是 CPU 密集，缓存解析结果（按 SQL 缓存）是关键优化。相同 SQL 复用解析可大幅降低开销，配合预编译与监控提升性能。

• 跨分片 Join 的问题
• 汇总层（宽表/ES）
• 全局查询方案

分库分表后 Join 涉及多个分片，跨分片 Join 需全路由扫描各分片再归并，性能差、复杂度高。方案是用汇总层替代：构建宽表（把关联数据冗余到一个表）或把数据同步到搜索/分析引擎（ES、OLAP），全局查询打到汇总层，避免跨分片 Join。宽表通过冗余字段减少关联，ES 提供灵活查询与聚合。数据从分片同步到汇总层（通过 binlog/Canal、双写）保证近似实时。这样把"跨分片 Join"转化为"汇总层单点查询"，简化并提速。

跨分片 Join 是分片后的痛点，汇总层（宽表冗余 + ES/OLAP 同步）用"空间换时间"规避 Join。同步保证近似一致性，查询集中到汇总层。

• SQL 改写
• 聚合归并
• 子查询处理

ShardingSphere 把原始 SQL 改写为分片可执行的 SQL（如把逻辑表改写为 t_order_0，把 LIMIT 改写为各分片 LIMIT），改写后各分片执行，再在中间层归并。聚合函数（SUM/COUNT/AVG）跨分片归并：各分片先算局部聚合，归并层再算全局（如 AVG 需各分片返回 sum 和 count 再求全局平均）。子查询与 ORDER BY/LIMIT 也需改写归并（如各分片取 LIMIT + OFFSET，归并层重新排序截取）。改写保证分片执行正确，归并保证结果正确，但复杂 SQL 改写与归并增加开销与正确性风险。

改写让分片正确执行，归并让跨分片结果正确。聚合/排序/分页/子查询的改写归并是关键，复杂 SQL 需谨慎处理。

• 双写
• 灰度切换
• 数据校验

分库分表扩容平滑迁移流程：新建目标分片 → 双写（新旧都写，保证增量一致）→ 全量数据迁移并校验（存量数据同步 + 抽样/全量比对）→ 灰度切换（先小流量切到新表，验证后放量）→ 割接完成（停旧写）。双写保证迁移期间增量不丢，数据校验（binlog 追平 + 比对）保证一致性，灰度切换降低风险。需处理：双写失败补偿、迁移期间的顺序保证、切换时短暂的只读/双写窗口。流程核心是"增量双写 + 存量校验 + 灰度切换"。

平滑迁移是"双写保增量、校验保一致、灰度降风险"。分阶段推进，每步可回滚，最后切换。核心是避免数据丢失与高风险一刀切。

• 字段加密算法
• 影子字段
• 密文查询支持

ShardingSphere Encrypt 支持字段加密：用 AES/SM4 等算法对敏感字段加密存储（密文），查询时解密。但普通加密字段无法用密文直接做等值/范围查询（密文不可比较）。影子字段（assistedColumn）是额外保存的辅助列：如加密的同时保存明文摘要（hash）或可查询的辅助值，用于支持查询（如身份证号加密后用 sha256 摘要列做等值查询）。这样既加密存储又支持查询。取舍：影子字段增加存储，且摘要列不如明文灵活，但解决了"加密后无法查询"的问题。

加密保住数据安全，但损查询能力。影子字段（辅助列）用摘要/辅助值支持等值查询，兼顾安全与功能。是加密与查询的平衡。

• 读写分离路由
• 主从延迟
• Hint 强制主库

读写分离默认把读路由到从库，但主从延迟会导致"刚写入读不到"的强一致问题。Hint 强制走主库（如 SQL 级 hint 或 ThreadLocal 路由上下文）让特定请求/事务强制走主库，保证读到最新数据。适用场景：写后立即读、事务内一致性、对延迟敏感的关键查询。取舍：强制主库增加主库压力、降低读写分离收益，因此只对关键路径用 Hint 强制主库，普通读走从库。工程上用 hint 平衡一致性与性能。

主从延迟破坏读写一致性，Hint 强制主库用"牺牲读分离"换"强一致"。只对关键路径使用，平衡一致性与主库压力。

• 分层编译（C1/C2）
• 内联启发式
• Graal 编译器

JVM 默认分层编译：先用 C1（客户端编译器）快速编译获得 profiling，再对热点方法用 C2（服务端编译器）做激进优化。C1 快速、优化轻，C2 慢但优化深（内联、逃逸分析、循环优化）。Graal 是新的 JIT 编译器（JVMCI），优化更激进、支持更先进技术。内联启发式：C2 根据调用频率、方法大小、热路径决定是否内联小方法（默认 MaxInlineSize 为 35 字节，热路径方法 FreqInlineSize 为 325 字节），减少调用开销。分层编译在"快速启动"与"深度优化"间平衡，内联是 C2 的核心优化之一。

分层编译（C1 快速 + C2 激进）平衡启动与峰值，Graal 提供新优化。内联按大小与热度启发式，减少调用开销。理解 JIT 利于解释性能。

• deoptimization 概念
• 触发原因
• 对性能观测的影响

deoptimization 是 JIT 编译的代码因假设失效而回退到解释执行或更低级编译版本。触发原因：类层次变化（如动态类加载使内联失效）、分支猜测错误、profile 污染、异常导致陷阱。影响：deoptimization 后热点方法回到低性能执行，产生性能波动（尖刺），且 JFR 中表现为 deoptimization 事件。对可观测性影响是：观测到的延迟/吞吐可能因 deoptimization 出现周期性尖峰，需结合 deoptimization 事件解释，避免误判为业务问题。优化方法是保持类层次稳定、避免 profile 污染。

deoptimization 让 JIT 优化回退，产生性能尖峰。观测时需识别 deoptimization 事件，解释异常延迟，避免误判服务器问题。

• NUMA 感知分配
• 压缩 oops
• 大堆优化

NUMA 感知分配：在多 CPU 节点（NUMA）机器上，JVM 可让对象分配在使用它的 CPU 所在节点内存（-XX:+UseNUMA），减少跨节点内存访问延迟，提升大堆吞吐。压缩 oops（CompressedOops）：堆大小 < 32GB 时，JVM 用 32 位压缩指针（-XX:+UseCompressedOops）表示对象引用，减少对象头与引用内存，降低堆占用与 GC 压力。大堆场景：启用压缩 oops 减少内存，NUMA 优化跨节点访问。二者配合优化大堆性能与内存效率。

压缩 oops 用 32 位指针省内存（<32GB 堆），NUMA 感知分配减少跨节点访问。大堆场景二者结合提升内存效率与吞吐。

• ZGC 收集器
• 亚毫秒暂停
• 16TB 堆扩展

ZGC 是并发的、基于 region 的收集器，目标亚毫秒级暂停。核心设计：用读屏障（load barrier）+ 染色指针（colored pointers）实现并发标记、并发转移，应用线程在 GC 时几乎不暂停（可"自愈"对象引用）。染色指针把 GC 状态编码进指针位，转移时无需 stop-the-world 完整扫描。ZGC 支持超大堆（设计可扩展至 16TB），通过多映射、染色指针与并发处理避免大堆长暂停。内存多占用（染色指针、多重映射）是代价，适合大堆低延迟场景。

ZGC 用读屏障 + 染色指针实现并发收集，达成亚毫秒暂停与 16TB 扩展。代价是内存开销，适合大堆低延迟。

• 热路径 JIT
• C2 内联
• 分片路由优化

分片路由热路径（高频 SQL 的解析、分片键提取、路由计算）会被 JIT 编译为优化机器码。C2 会把热路径上的小方法内联（如分片键提取、取模计算、路由判断），减少调用开销，配合逃逸分析、分支预测优化。这样高频 SQL 的路由计算极快，避免解释执行。优化前提是热路径稳定、方法小而清晰、无多态导致内联失效。实测中可观察 JIT 编译日志（-XX:+PrintCompilation）确认热点方法被编译与内联。

C2 内联热路径小方法，把分片路由计算优化为高效机器码。保持热路径稳定简单利于内联，是提升路由性能的关键。

• Snowflake 主键
• 时钟回拨
• UUID 冲突

Snowflake 主键由时间戳 + 机器标识 + 序列号组成，天然有序、适合分片路由（按时间范围）。但依赖时钟，时钟回拨会导致 ID 重复或乱序，需策略规避（如等待、偏移、错误拒绝）。UUID 无序、随机，无时钟依赖不冲突（概率极低），但作为分片键时分布均匀但无法按时间路由，且 UUID 较大（字符串）影响索引与存储。分片环境下：Snowflake 有序利于范围分片与索引，但需处理时钟回拨；UUID 均匀利于取模分片，但无序、大。选型权衡有序性、大小与时钟依赖。

Snowflake 有序适合分片但依赖时钟，UUID 均匀但无序大。时钟回拨是 Snowflake 核心风险，需等待/偏移/拒绝策略。

• 分片键变更代价
• 数据重分布
• 路由规则升级

修改分片键会破坏现有数据分布，代价巨大：所有数据需按新分片键重新分片（数据重分布），涉及全量迁移、双写、校验；路由规则需升级（配置变更、应用重启/热更新）；历史数据按旧键的查询需迁移或兼容；业务代码中依赖旧分片键的 SQL 需调整。这是高成本、高风险的工程操作，需线上迁移演练、灰度、回滚方案。实践中分片键应选稳定、高频查询的字段，避免变更。分片键变更本质上等于"重新分库分表"。

分片键是路由的根基，变更引发全量重分布与规则升级，成本近似重做分片。所以选分片键要前瞻稳定，避免后期变更。

• 本地索引
• 全局索引（GSI）
• 查询路径差异

本地索引（Local Index）只在所在分片内有效，索引与数据同分片；按非分片键查询时，需全路由扫描所有分片各自的本地索引再归并（query_all_dbs）。全局索引（Global Secondary Index，GSI）是独立于数据的索引表，按索引键路由，查询时直接定位到索引所在分片，再回表取数据，避免全路由。差异：本地索引查询非分片键要全分片扫描，性能差；全局索引用索引空间换查询效率，但增加索引维护成本与一致性复杂度。大数据量高频非分片键查询应建 GSI。

本地索引无跨分片能力（全路由），全局索引按索引键路由（定位快）。GSI 用存储换查询性能，适合高频非分片键查询。

• 分片连接池
• 连接内存占用
• 容量规划

每个分片都配置连接池，连接本身占用内存（Socket 缓冲、Statement 缓冲、结果集缓存、连接对象）。连接总数 = 分片数 × 每分片连接池大小。总堆内存需容纳：连接相关缓冲 + 业务对象 + 缓存 + 结果集 + 余量。若连接数大而堆小，连接缓冲与并发结果集挤压堆，导致 GC 频繁或 OOM。规划：先算每连接缓冲（如 X KB）× 总连接数，加上业务与缓存需求，确定堆大小，并按此限制连接池大小，避免"连接多堆小"。连接池线程数也需与堆匹配。

分片数放大连接数，连接缓冲 × 总连接数 + 业务内存 = 堆需求。规划需让连接池与堆匹配，避免资源挤压。

• 本地事务
• 尽力送达消息
• 柔性事务

"本地事务 + 尽力送达消息"是柔性事务方案：本地事务内完成业务操作并写入消息（如把消息写入本地消息表），本地事务提交后异步发送消息，消息尽力送达下游（带重试与幂等）。若消息发送失败，通过定时扫描消息表重发。这样本地事务保证数据一致，消息解耦下游，最终一致性由消息重试保证。适用于分片场景下"本地强一致 + 跨服务最终一致"的柔性事务，避免复杂分布式事务。核心是"本地事务 + 消息表 + 重试幂等"。

本地事务保证本库一致，消息表 + 重试保证跨服务最终一致。用"本地事务 + 消息"替代分布式事务，降低复杂度。

• 调度指标
• 执行耗时与成功率
• 链路追踪埋点

调度系统可观测性需采集：执行耗时（调度延迟、执行时间、结束时间）、成功率（成功/失败/超时次数）、任务队列长度、并发执行数。埋点：在任务执行入口/出口记录耗时与结果，用 Counter 统计成功率、Timer 记录耗时分位数；用链路追踪（trace）把调度触发、任务执行、下游调用串联，定位调度延迟与失败环节。指标用于监控与告警（如失败率、延迟超阈值），追踪用于根因定位。需覆盖调度、执行、下游三个环节。

可观测性是"指标（耗时/成功率）+ 追踪（链路）"。指标监控健康，追踪定位根因，覆盖调度到执行的完整链路。

• 逃逸分析
• 标量替换
• 锁消除

逃逸分析（Escape Analysis）分析对象的引用是否逃逸出方法/线程。若对象不逃逸，JIT 可做：标量替换（Scalar Replacement）把对象拆分为标量字段，栈上分配或直接寄存器，消除堆分配；锁消除（Lock Elision）移除对不同线程不可见的锁（如局部对象上的 synchronized），消除锁开销。这些优化减少堆分配与锁竞争，提升性能。前提是对象不逃逸、锁不可见。理解帮助优化代码（避免不必要逃逸、减少加锁）。

逃逸分析识别不逃逸对象，标量替换消除堆分配，锁消除消除无用锁。三者基于"不逃逸/不可见"假设，减少开销。

• CDS 共享类数据
• AppCDS 应用类共享
• 启动优化

CDS（Class Data Sharing）把 JVM 核心类预先处理成共享归档，多个 JVM 进程共享，减少类加载与内存占用。AppCDS（Application CDS）扩展 CDS，把应用类也归档为共享（需先跑一次 dump 生成归档），启动时从归档加载类，减少类解析与验证时间，显著降低启动时间（对容器/Serverless 冷启动尤其有用）。原理是利用归档避免重复的类加载与验证。容器场景用 AppCDS 归档可减少启动到就绪的时间，配合 Spring 应用优化。

CDS/AppCDS 用"类归档共享"减少类加载与验证，缩短启动。AppCDS 把应用类归档，对容器冷启动优化明显。

• 加密列性能
• 密文索引
• 影子字段取舍

加密列把敏感字段加密存储，查询时解密，解密增加 CPU 开销。普通密文无法直接用于索引（密文不可比较/无顺序），无法做等值/范围索引，导致查询性能下降。取舍：密文索引（如对密文做等值 hash 索引）牺牲部分灵活性支持等值查询；影子字段（assistedColumn）额外存辅助摘要列支持查询，但增加存储与写入开销。权衡：安全优先用加密但牺牲索引与查询性能，需要查询能力则用影子字段/密文索引，权衡存储、写入与查询的平衡。

加密保安全但损查询/索引。密文索引与影子字段用"辅助可查询列"恢复等值查询，代价是存储与写入。取舍看安全与查询需求。

• 雪花主键路由
• 时钟回拨
• 规避策略

ShardingSphere 内置雪花算法生成分布式主键。雪花 ID 含时间戳，单调递增，可用于范围分片/按时间路由；生成时作为分片键值参与路由计算。时钟回拨风险：若系统时钟回拨，生成的时间戳变小，导致 ID 重复或乱序。规避策略：ShardingSphere 检测到时钟回拨时拒绝生成（抛异常）、等待时钟追平、或维护最大时间戳并偏移（在两毫秒内用序列号扩张）。实际实现记录最大生成时间，回拨时等待或报错，保证 ID 唯一性。

雪花 ID 单调有序利于分片路由，但依赖时钟。规避时钟回拨是"记录最大时间 + 回拨等待/拒绝/序列号扩展"，保证唯一与单调。

• G1 停顿
• 批量导入
• 降低 GC 频率

分片批量导入会产生大量临时对象（结果集、批处理缓冲），导致 GC 频繁、停顿（G1 的 Mixed GC 停顿）。配合策略：复用缓冲与对象减少分配（减少垃圾）、控制批次大小避免瞬时对象洪峰、合理设置堆大小与 G1 参数（-XX:MaxGCPauseMillis、G1 的 region 与并发周期）、在导入窗口调整 GC 参数（如增大堆、调高吞吐模式）、避免在 GC 高峰做超大批。目标是降低分配率、减少 GC 停顿对写入吞吐的影响。

批量导入的高分配率放大 GC。降低 GC 频率靠"复用对象降分配 + 合理堆/G1 参数 + 批次控制"，平衡吞吐与停顿。

• Inline 分片
• Standard 分片
• Complex 分片

四类分片策略：Inline（行内表达式，如 t_order_$->{order_id % 2}，简单取模/哈希，适合单分片键等值/范围简单场景）；Standard（标准，支持单分片键的精确与范围分片，用算法配置，适合等值+范围）；Complex（复合，支持多分片键的精确匹配，适合按多字段路由）；Hint（强制路由，不依赖分片键，通过 ThreadLocal/hint 指定分片，适合分片键缺省或特殊路由）。场景：简单取模用 Inline，需要范围用 Standard，多键复合用 Complex，无法从 SQL 推断分片键用 Hint。

四类策略覆盖从简单到复杂的路由：Inline 表达式、Standard 单键、Complex 多键、Hint 强制。按分片键数量与路由方式选型。

• 事务日志
• 堆外内存
• 配置关系

分库分表后，XA/分布式事务的日志（redo/undo、事务协调日志）可能与 JVM 堆外内存（direct memory、Netty 缓冲、GC 未管理内存）相关：事务日志的持久化、缓冲可能用堆外内存；XA 事务管理器的日志缓冲、连接缓冲也占堆外。配置关系：堆外内存大小需与并发事务、日志缓冲匹配，若堆外内存不足会 OOM（如 Direct buffer memory）。规划时需同时考虑堆与堆外（MaxDirectMemorySize），并让事务日志缓冲与堆外余量匹配，避免堆外耗尽。

事务日志/缓冲可能用堆外内存，需配置 MaxDirectMemorySize 与并发事务匹配。堆与堆外联动规划，避免堆外 OOM。

• 读写分离路由
• 主从延迟
• 事务一致性

读写分离把读路由到从库、写路由到主库。主从延迟导致从库数据滞后，读到的可能不是最新数据，影响"写后读"一致性。影响：路由上，若读走了从库，可能读到旧数据；事务内或对一致性敏感的操作若走从库，破坏事务一致性。ShardingSphere 处理：事务内（事务开启后）强制走主库；可通过 Hint 强制主库；对一致性敏感查询路由主库。应对延迟：延迟监控、读写分离阈值、对关键读强制主库。一致性需求高的场景需主从延迟可控或强制主库。

主从延迟破坏"写后读"一致。ShardingSphere 用事务内强制主库、Hint 强制主库应对，敏感性查询走主库保一致。

• 单分片数据量
• 连接数与堆
• 容量估算

分片容量规划需估算：单分片数据量（决定分片数，避免单分片过大或过小）、连接数（分片数 × 每分片连接池，决定并发与内存）、JVM 堆（连接缓冲 + 业务 + 缓存 + 结果集）。估算流程：先按总数据量与单分片目标容量确定分片数；再定每分片连接池大小，乘分片数得总连接数；总连接缓冲 + 业务堆需求 + 余量 = 堆大小。需平衡：分片数多则连接与运维成本高，分片少则单分片压力大。堆与连接需联动，避免资源失衡。

容量规划是"数据量定分片数、连接数定并发、堆定内存"的联动估算。三要素匹配才能稳定运行，避免单分片过大或连接拖垮堆。

• Seata AT 模式
• 集成 ShardingSphere
• 最终一致

Seata AT 模式基于"两阶段 + 补偿"实现最终一致：第一阶段直接提交本地事务并记录 undo log（回滚日志），第二阶段根据全局事务结果：成功则异步删除 undo log，失败则用 undo log 反向补偿回滚。Seata 集成 ShardingSphere：把 ShardingSphere 管理的多个分片数据源纳入 Seata 全局事务，作为 AT 分支注册，跨分片事务通过 Seata 协调实现最终一致。相比 XA，AT 不锁资源、性能好，用 undo log 补偿实现柔性事务。适合性能敏感、可接受最终一致的跨分片事务。

AT 模式用"本地提交 + undo log 补偿"实现最终一致，比 XA 性能好。与 ShardingSphere 集成把分片纳入全局事务，协调跨分片最终一致。

• Infra 基础层
• Kernel 内核层
• Features 功能层

ShardingSphere 5.x 采用分层模块化架构：Infra（基础设施层）提供核心基础（配置、元数据、数据库访问、SPI 扩展）；Kernel（内核层）提供 SQL 解析、路由、改写、执行、归并等核心能力；Features（功能层）提供分片、读写分离、加密、影子、数据脱敏等具体功能。功能层基于内核的解析/路由/执行能力实现，通过 SPI 扩展，JDBC 与 Proxy 两种形态共享内核。架构上分层清晰、功能可插拔，便于扩展新功能。

Infra/Kernel/Features 三层架构：Infra 是基础，Kernel 是核心能力，Features 是具体功能。SPI 扩展让功能可插拔，JDBC/Proxy 共享内核。

• 加密拦截
• 明文/密文处理
• 拦截原理

ShardingSphere Encrypt 在 SQL 解析与改写环节拦截：对 INSERT/UPDATE 的加密字段，利用 SQL 改写把明文替换为加密后的密文（通过加密算法计算）；对 SELECT 的加密字段，改写为对密文列查询，并在结果归并时对密文解密为明文返回。配置 Encrypt 规则（加密列、算法、辅助列）后，应用透明读写明文，底层自动加解密。原理是"解析改写 + 结果归并解密"，让应用无感知地完成敏感字段加密。

Encrypt 用"改写 SQL 加密写入 + 归并结果解密"实现透明加解密。应用读写明文，底层存密文，是拦截器式的数据安全方案。

• Scaling 在线扩缩容
• 存量迁移
• 增量同步

ShardingSphere Scaling 是数据迁移/扩缩容组件：在线扩缩容时，新建目标分片拓扑，通过"存量数据迁移 + 增量同步"把数据从旧分片迁到新分片，期间业务不停。存量迁移用全量抽取（读旧写新），增量用 binlog 订阅同步变更，最终追平后切换。切换时先校验存量+增量一致性，再切换流量（短暂只读或双写）。支持动态扩缩容，避免停机。核心是"全量 + binlog 增量 + 校验 + 切换"，保证在线迁移正确。

Scaling 用"全量迁移 + binlog 增量 + 一致性校验 + 切换"实现在线扩缩容。迁移期间业务不停，切换前校验一致性。

• 集成方式
• 常见陷阱
• 规避

ShardingSphere 与 MyBatis/Spring Data 集成常见陷阱：数据源配置（需用 ShardingSphere 的 DataSource 替换 MyBatis 默认数据源）；事务管理（分布式事务需配置 ShardingSphere 事务，普通事务管理器不覆盖多分片）；分片键必须出现在 SQL 否则全路由；MyBatis 的批量操作、动态 SQL 生成的分片键识别；Mapper 的缓存与分片结果不一致；Spring Boot 的自动配置覆盖。规避：确保分片键在 SQL 中、正确配置数据源与事务、避免依赖分片键的缓存。

集成陷阱集中在"数据源替换、事务、分片键识别、缓存"。确保分片键入 SQL、配置正确数据源与事务，可避免大部分问题。

• 元数据管理
• 配置中心
• 动态更新

ShardingSphere 支持把元数据（分片规则、数据源、加密规则）与配置注册到配置中心（ZooKeeper/Nacos），实现分布式配置与动态更新。配置中心存储规则配置，多个实例共享同一份配置，变更后通过监听（watch）推送，实现热更新（无需重启应用）。元数据（表结构等）也可集中管理。集成后，配置变更、灰度、多实例一致性由配置中心协调，提升了运维能力。ShardingSphere 的 ConfigCenter 抽象支持 ZooKeeper/Nacos/Etcd 等。

配置中心集中管理规则并热更新，多实例共享配置。ZooKeeper/Nacos 监听变更实现动态路由规则，是运维与灰度基础。

• 国产数据库适配
• 兼容性
• 注意点

信创国产库（如 OceanBase、TiDB、GaussDB、达梦、人大金仓等）与 MySQL/PG 的方言、驱动、协议有差异。ShardingSphere 适配注意点：方言解析（SQL 解析需支持国产库方言，如不支持的函数需要扩展）；驱动与连接（JDBC 驱动、URL 格式差异）；分布式事务（国产库的 XA/分布式事务能力差异）；分片函数与内置函数兼容；类型映射。需针对性做方言适配与全量回归测试，确认解析、改写、执行在国产库上正确。必要时用 Proxy 形态降低侵入。

国产库适配关键在"方言解析、驱动、事务、类型映射"。需逐库验证与回归，必要时用 Proxy 隔离差异。

• 单元化
• 异地多活
• 分片路由

异地多活单元化把业务按单元（如用户、地域）划分，每个单元独立成可用区，数据按单元维度分片。ShardingSphere 的分片路由策略在单元化中：分片键带单元维度（如 user_id 含单元位），路由规则把单元路由到对应机房/单元，保证单元内数据自治、就近处理。核心是"单元维度分片 + 路由到单元 + 单元内读写"。事务和数据一致性限制在单元内，跨单元操作通过异步/全局协调。ShardingSphere 通过分片键规划把同一单元的数据路由到同一物理分片，支撑单元化。

单元化用"单元维度分片 + 路由到单元"实现就近自治。分片键含单元标识，路由保证单元内数据与事务一致，跨单元弱一致。

• 数据脱敏
• 动态脱敏
• 规则配置

ShardingSphere 支持数据脱敏：静态脱敏（写入时加密，如 Encrypt 加密）与动态脱敏（查询时按规则隐藏，如手机号显示 138****1234）。动态脱敏规则配置：通过脱敏算法（如 md5、遮罩、替换）对查询结果处理，配置脱敏列与算法、脱敏类型（如明文脱敏、密文脱敏）。ShardingSphere 在结果归并时对脱敏列应用算法，返回脱敏数据。配置规则（脱敏列、算法、适用场景）后，应用写入或查询时自动脱敏，保护敏感数据，且支持按权限/场景动态脱敏。

数据脱敏分"写时加密"与"读时遮罩"。ShardingSphere 用规则配置脱敏列与算法，在访问/归并层透明脱敏，保护敏感数据。

• 权限控制
• SQL 防火墙
• 安全能力

ShardingSphere 提供权限控制与 SQL 防火墙：权限控制基于用户/角色对数据库访问授权（Proxy 支持用户认证与权限管理）；SQL 防火墙（SQL Firewall）拦截并校验 SQL，按规则放行或拒绝（如限制高风险 SQL、黑名单、SQL 注入检测、高危操作拦截）。防火墙在 SQL 执行前检查，防止恶意/非法 SQL 破坏。配置权限（用户权限级别）与防火墙规则（SQL 类型、表、关键字），实现访问控制与安全防护。适用于 Proxy 形态的集中管控。

权限控制管"谁能访问"，SQL 防火墙管"什么 SQL 可执行"。二者配合提供访问控制与 SQL 安全防护，适合 Proxy 集中管控。

• DistSQL 概念
• 在线变更
• 运维能力

DistSQL（Distributed SQL）是 ShardingSphere 的运维语言，类似 SQL 的语法用于管理分片规则、数据源、配置。通过 DistSQL 可在线执行：创建/修改数据源、配置分片规则、查看路由计划、扩缩容、管理配置中心等，无需重启应用。DistSQL 提供 CREATE DATABASE、ADD DATA SOURCE、EXPLAIN SHARDING PLAN 等，实现"在线变更配置"。它把 ShardingSphere 的运维操作标准化为 SQL 风格命令，提升运维效率与可编程性。

DistSQL 用 SQL 风格语法在线管理分片规则与数据源，实现热变更与运维可编程。是 ShardingSphere 的运维接口。

• SQL 解析
• 改写
• 路由

ShardingSphere 处理 SQL 的流程：解析（用 ANTLR 把 SQL 解析为 AST，生成逻辑查询计划，提取表、分片键、条件）→ 路由（根据分片键与规则确定目标分片）→ 改写（把逻辑表改写为真实表名，按路由结果改写 SQL，如把 t_order 改为 t_order_0，改写 LIMIT、聚合）→ 执行（在目标分片执行改写后的 SQL）→ 归并（聚合归并结果）。核心是"解析出路由信息 → 改写为可执行 SQL"。路由依赖解析出的分片键值，改写保证每个分片执行正确的 SQL。

处理流程是"解析→路由→改写→执行→归并"。解析提取路由信息，路由定分片，改写定 SQL，归并定结果。理解此链路是掌握 ShardingSphere 的关键。

• 主从路由
• 负载均衡算法
• 读写分离

ShardingSphere 读写分离，写操作路由主库，读操作按负载均衡算法路由从库。负载均衡算法：ROUND_ROBIN（轮询）、RANDOM（随机）、WEIGHT（权重，按从库权重分配）。路由规则考虑：事务内强制主库、Hint 强制主库、明确的读方法。从库负载均衡在多个从库间分配读流量，避免单从库过载。配置负载均衡算法与从库列表，实现读写分离与读流量均衡。主从延迟由 SQL 路由与强制主库机制控制。

读写分离"写主读从"，从库用轮询/随机/权重均衡。事务内或敏感读强制主库，保证一致。负载均衡算法分散读流量。

• JDBC 形态
• Proxy 形态
• 差异与选型

ShardingSphere-JDBC 是嵌入式形态：以 JDBC 驱动/数据源形式集成进应用，应用直连分片，无中间网络，性能好、部署简单，但每个应用需引入分片库、分片逻辑在应用内（语言绑定）。ShardingSphere-Proxy 是独立代理形态：作为独立服务接受客户端连接，应用通过标准 JDBC 连接 Proxy，分片逻辑在 Proxy 端，语言无关、可集中管控，但增加一跳网络与性能开销。差异：JDBC 轻量、高性能、语言绑定；Proxy 独立、语言无关、集中管理。选型看侵入性、语言栈与运维需求。

JDBC 嵌入式（性能好、侵入应用），Proxy 独立代理（语言无关、集中管控）。选型在侵入性、性能与运维能力间权衡。

• 连接池集成
• 连接管理
• 分片连接

ShardingSphere-JDBC 作为数据源，内部为每个分片配置一个连接池（如 HikariCP），每个分片连接池独立管理到该分片的连接。应用从 ShardingSphere 数据源获取连接后，SQL 路由时按需从对应分片连接池取连接执行。连接管理：分片连接池大小影响并发，需按分片配置；事务跨分片时，ShardingSphere 用多个分片连接协调（XA 需多个连接参与事务）。HikariCP 的池化、连接复用、超时配置直接影响性能。需合理配置每个分片连接池大小与全局并发。

JDBC 形态为每个分片配置独立连接池，路由时按分片取连接。连接池大小与并发、事务协调相关，需按分片规划。

• SQL 审计
• 慢 SQL 拦截
• 性能定位

ShardingSphere 提供 SQL 审计与慢 SQL 拦截：审计记录执行的 SQL（路由、改写、实际执行的分片），慢 SQL 拦截记录超过阈值的 SQL 及耗时。定位跨分片查询性能问题：通过审计日志/慢 SQL 看哪些 SQL 被全路由（无分片键）、跨多少分片、改写后执行情况、归并耗时。全路由（query_all_shards）是跨分片查询性能差的主因；查询分散到多分片再归并，耗时放大。据此优化：加分片键、建 GSI、改汇总层、优化 SQL。审计与慢 SQL 是定位分片性能的关键数据。

慢 SQL/审计暴露"全路由、跨分片、归并耗时"。定位后用加分片键、GSI、汇总层优化。是分片性能诊断入口。

• 分片延迟
• 路由次数
• 数据倾斜

分库分表监控指标：分片延迟（各分片响应/主从延迟）、路由次数（单 SQL 路由到多少分片，反映全路由）、数据倾斜（各分片数据量/请求量分布）、分片 QPS 与耗时、慢 SQL。观测：按分片维度统计延迟与吞吐，识别热点分片；路由次数高说明分片键缺失或分布不均；数据倾斜用各分片行数/请求占比检测，倾斜会导致部分分片过载。指标用于发现全路由、热点、倾斜，指导分片键优化与再平衡。

监控重点在"分片延迟、路由次数、数据倾斜"。延迟看性能，路由次数看全路由，倾斜看热点。据此优化分片与路由。

• 直接内存
• Netty/缓冲池
• 数据迁移内存边界

分片批量导入/数据迁移（如 Scaling 的批量写、Netty 传输）会用直接内存（Direct ByteBuffer）与缓冲池（Netty 的 PooledByteBufAllocator）。直接内存不归堆管理，属 off-heap，由 MaxDirectMemorySize 限制。若导入并发大、缓冲池分配多，直接内存可能耗尽（Direct buffer memory OOM）。内存边界：需配置 MaxDirectMemorySize 与 Netty 缓冲池大小，按并发迁移与批大小规划，避免直接内存超限；同时控制批量大小与缓冲复用，减少 off-heap 峰值。规划时堆与直接内存都需考虑。

数据迁移的 Netty/缓冲池用直接内存，需 MaxDirectMemorySize 与缓冲池配置匹配并发。控制批大小与缓冲复用防直接内存 OOM。

• 配置中心热更新
• 规则变更
• 灰度

ShardingSphere 集成配置中心（ZooKeeper/Nacos）后，分片规则存储在配置中心，实例监听变更实现热更新：修改配置中心的分片规则，实例收到通知自动加载新规则，无需重启。灰度：通过配置多个规则版本/带灰度的规则，对部分流量（按实例、标记）应用新规则，逐步验证后全量，实现规则灰度切换。热更新与灰度让分片规则变更可在线上平滑推进，降低风险。注意变更需保证规则一致性（所有实例最终一致）与兼容性。

配置中心 + 监听实现规则热更新，多版本/标记实现灰度。规则变更平滑推进，需保证实例间一致与兼容。

• 跨分片分页
• 归并
• 性能优化

分片下分页：LIMIT/OFFSET 需各分片取 (OFFSET + LIMIT) 条，归并层排序后截取，OFFSET 越大取越多、性能越差。优化：用游标分页（cursor/timestamp）替代 OFFSET，基于上次位置定位，避免深度 OFFSET；减少每分片取数（若排序键与分片键一致可缩小范围）；用全局索引/汇总层支撑分页；合理索引。深度分页（大 OFFSET）是分片分页性能痛点，游标分页是主要优化手段。

OFFSET 分页在分片下取数放大（OFFSET×分片数），游标分页消除深 OFFSET。排序键与分片键配合可优化范围。

• 流式归并
• 内存归并
• 大结果集

分片结果归并有两种：流式归并（stream merge）边读边处理，不一次性加载全部结果，内存压力小；内存归并（in-memory merge）把各分片结果全部加载到内存再归并（如排序、聚合），大结果集内存压力大。ShardingSphere 对 ORDER BY、聚合等可能用内存归并，对简单 LIMIT 等用流式。大结果集 + 内存归并可能 OOM。优化：减少每分片取数、用流式归并、避免全量排序、用汇总层/游标。需按结果集大小选择归并策略。

流式归并省内存，内存归并需全量加载。大结果集排序/聚合归并内存压力大，需减少取数、用流式或汇总层。

• 对账任务
• 不一致发现
• 补偿

分片事务（尤其柔性/最终一致）会对账与补偿：对账任务定期比对各分片/参与方的事务状态与数据，发现不一致（如某分片提交成功、另一分片未提交/回滚）。对账用"对账表 + 状态比对"：记录事务的全局状态与各分片状态，对账任务比对差异；发现不一致后依据日志/状态触发补偿（正向补偿补齐，或反向补偿回滚）。补偿需幂等。对账周期、比对范围、补偿策略需配置，保证最终一致。对账是分布式事务一致性的兜底。

对账靠"状态比对发现差异"，补偿靠"幂等重放/回滚恢复"。对账是最终一致的兜底，发现不一致后触发补偿闭环。

• 分片键选择
• 热点避免
• 跨分片查询

分片键选择原则：选择高频查询、等值/范围查询多的字段，保证大多数查询能被路由（避免全路由）；选择值分布均匀的字段（避免热点分片）；与业务核心维度对齐（如用户、订单）。热点设计：避免分片键值集中在少数值（如按用户但少数大用户占多数），可用哈希/业务维度打散；分片键值分布均匀减少数据倾斜。避免跨分片查询：让分片键字段覆盖主要查询条件，减少全路由。分片键的选择直接影响路由效率与均衡性。

分片键要"高频、均匀、路由友好"。避免热点靠均匀分布，避免跨分片靠覆盖主要查询。分片键是分片设计的核心。

• 全路由
• Hint 路由
• 索引兜底

SQL 中无分片键时，ShardingSphere 无法确定分片，会全路由扫描所有分片（query_all_shards），性能差。避免方案：Hint 路由（强制指定分片，通过 ThreadLocal/hint 显式路由，不依赖 SQL 分片键）；索引兜底（用全局二级索引 GSI 按非分片键查询，避免全路由）；或业务上保证 SQL 带分片键。设计上：对无法带分片键的查询用 Hint 指定分片，或依赖 GSI 的索引表定位。全路由是性能杀手，应通过 hint、GSI 或优化 SQL 避免。

缺分片键触发全路由，用 Hint 指定分片或 GSI 索引表定位。避免全路由是分片查询性能的关键。

• 广播表
• 绑定表
• 单表

广播表（Broadcast Table）：每个分片都有一份相同数据（如配置表），所有分片都存，读本地即可，写广播到所有分片，用于常量/配置类数据。绑定表（Binding Table）：分片键一致、逻辑关系相关的表（如 t_order 与 t_order_item 按 order_id 分片），保证 JOIN 时数据在同一分片，避免跨分片 JOIN。单表（Single Table）：不分片的表，ShardingSphere 统一管理路由到单库。特殊处理：广播表全分片冗余、绑定表分片键对齐、单表路由到指定库。三者是分片拓扑中的特殊表类型。

广播表冗余到所有分片（读本地）、绑定表分片键对齐（JOIN 同分片）、单表路由单库。三者解决不同的数据分布需求。

• 范围分片
• 取模分片
• 迁移成本

取模分片（mod）扩容时，分片数变化导致取模结果全部变化，几乎所有数据需重新分布（迁移成本高，需全量重迁移）。范围分片（range）按值范围分片，扩容时新增范围分片，旧分片数据基本不变，只需迁移新增范围的数据（迁移成本低），但范围分片可能数据倾斜（热点范围）。权衡：取模分片分布均匀但扩容迁移成本高；范围分片扩容迁移少但易倾斜。需在"分布均匀"与"扩容迁移成本"间选型。

取模扩容全重分布（成本高），范围扩容增量迁移（成本低但易倾斜）。选型权衡均匀性与扩容成本。

• 启动预热
• 连接初始化
• 首请求延迟

首请求延迟偏高源于：JIT 未编译（冷启动解释执行）、连接池未初始化（懒加载）、类加载、缓存未填充。避免方案：启动预热（启动后预热关键路径，触发 JIT 编译与缓存填充）；连接池预初始化（连接池初始即建连接，避免首请求建连）；类加载预热；预填充缓存。分片环境每个分片连接池都需初始化，热点 SQL 需预热编译。通过预热减少首请求延迟，提升启动后首次响应体验。

首请求延迟来自"冷启动（JIT/加载/缓存）+ 连接懒建"。预热关键路径与连接池预建，消除首请求尖刺。

• 数据一致性校验
• 抽样比对
• 对账任务

分库分表后数据一致性校验用"抽样比对 + 对账任务"：抽样比对（对数据按规则抽样，比对源与目标/分片间的数据是否一致，用 hash 或关键字段比对，减少全量开销）；对账任务（定期对账，比对各分片与汇总/目标的数据，发现不一致并触发补偿）。设计：定义对账维度（如按主键、按分片）、比对方式（全量/抽样、hash 校验）、对账周期、不一致处理。抽样比对降低比对成本，对账任务持续兜底一致性。

一致性校验用抽样（降本）+ 对账（兜底）。比对关键字段/hash，发现不一致触发补偿，保证分片数据一致。

• 加密升级
• 存量明文
• 平滑迁移

已有明文存量数据要升级为加密存储，需平滑迁移：ShardingSphere 加密支持"明文+密文"双列过渡（如 encryptor 的 assistedQuery 与明文列），迁移期间同时存明文与密文，存量数据先读明文、新写加密；通过数据迁移任务把存量明文加密为密文，追平后切换只读密文（删除明文列）。配合 Encrypt 的算法与规则，实现存量明文平滑升级为密文，业务无感。核心是"双列过渡 + 存量加密 + 切换"。

明文升密文用"双列过渡（明文+密文）+ 存量加密 + 切换"平滑升级，业务无感。是加密落地的安全迁移路径。

• 跨分片更新
• 部分成功
• 一致性保证

跨分片更新涉及多个分片，若部分成功、部分失败，导致数据不一致。避免方案：用分布式事务（XA 强一致或 Seata 柔性最终一致）保证跨分片原子性；或通过"ID 生成 + 幂等 + 补偿"实现最终一致；或设计上避免跨分片更新（按分片键拆分为单分片更新）。XA 保证全成功或全回滚，Seata 用补偿保证最终一致，尽最大努力。对不可用分布式事务的场景，用对账+补偿兜底。核心是让跨分片更新"要么全成、要么可补偿"。

跨分片更新的不一致靠"分布式事务（XA 原子/Seata 补偿）"或"拆分为单分片更新 + 对账补偿"避免。设计上尽量规避跨分片更新。

• GC 日志
• 写入吞吐
• GC 尖刺定位

用 -Xlog:gc（或 -Xlog:gc*）输出 GC 日志，分析 GC 停顿时间、频率、暂停原因。关联分片写入吞吐：把 GC 停顿时间与写入吞吐/延迟曲线叠加，若写入尖刺（延迟升高、吞吐下降）与 GC 停顿时间吻合，说明 GC 引起写入尖刺。定位方式：GC 日志看停顿类型与严重性（如 Full GC、Mixed GC）、分配率；对比写入时段；用 JFR 的 GC 事件与写入指标关联。定位后优化：降低分配率（复用对象）、调 G1 参数、增大堆、控制批量，减少 GC 停顿对写入的影响。

用 GC 日志时间与写入吞吐曲线叠加，定位 GC 停顿导致的写入尖刺。优化降低分配率与停顿，平滑写入。

• 绑定表 Join
• 广播表 Join
• 应用边界

绑定表（分片键一致、逻辑相关）在 Join 时保证关联数据在同一分片，可本地 Join，避免跨分片 Join，是绑定表的核心应用。边界：仅当绑定表分片键一致、使用分片键 JOIN 时才能本地 Join；若 JOIN 键不是分片键，仍会跨分片。广播表（每分片相同）可本地 Join 常量表，但写放大（每分片都写）。边界：绑定表用于"主从业务表按同分片键 Join"，广播表用于"小常量表 Join"，超出此边界（跨分片键 Join）需汇总层或非 Join 方案。

绑定表 Join 边界是"分片键一致 + 用分片键关联"，广播表边界是"小常量表全分片冗余"。超出边界需汇总层。

• 结果集内存
• 大批量查询
• 堆压力

分片查询的大批量结果集（取全量、深度分页、全路由）会一次性加载大量数据到堆，对堆造成压力，可能导致 OOM 或频繁 GC。分片放大：跨分片查询把各分片结果加载到内存再归并，内存占用为"结果集 × 分片数"。缓解：限制每分片取数（LIMIT）、流式读取、游标分页、分批处理、避免全路由、用汇总层。大批量查询结果集是堆压力的主要来源，需控制取数与归并内存。

分片放大结果集内存（×分片数），大批量查询易 OOM。限制取数、流式、游标、分批缓解堆压力。

• 路由规则测试
• SQL 改写验证
• 分片键场景

分片路由规则的单元测试：用不同分片键值执行 SQL，验证路由结果（SQL 被路由到哪个分片）与改写结果（逻辑表名改写为哪个真实表名、SQL 形态）。做法：构造 ShardingSphere 数据源，用多种分片键（边界值、取模边界、范围边界）执行 SQL，断言实际执行的分片表名与改写 SQL。可用 EXPLAIN 查看路由计划，或捕获实际执行的 SQL。覆盖：等值/范围/无分片键（全路由）、多分片键、聚合改写。这样验证路由规则正确性。

路由测试用多样分片键断言"路由到哪个分片 + 改写为哪个真实表"。覆盖边界与全路由场景，验证规则正确。

• Metaspace
• 动态 SQL 生成
• 元空间占用

Metaspace 存放类元数据（类结构、方法、常量池）。分片 SQL 动态生成（ShardingSphere 运行时生成改写 SQL、动态 SQL 类、表达式）可能产生大量类/字符串，占用 Metaspace。若动态生成类无界（如每次生成新类、反射生成代理类），Metaspace 持续增长，可能导致 Metaspace OOM。优化：控制动态类生成、复用 SQL 解析缓存、避免每次生成新类（用缓存/预编译）、监控 Metaspace 大小。动态 SQL 的临时字符串多在堆，类元数据在 Metaspace，需区分。

动态生成类/字符串占 Metaspace，无界增长会 OOM。用缓存复用、避免重复生成类、监控 Metaspace 控制占用。

• 本地索引
• GSI
• 取舍

分片环境下索引设计：本地索引（Local Index）在分片内，只能服务本分片查询，按非分片键查询需全路由；全局二级索引（GSI）独立索引表，按索引键路由，避免全路由，服务高频非分片键查询。取舍：本地索引零额外成本但跨分片查询靠全路由；GSI 用存储与维护成本换查询效率，但增一致性复杂度（索引与数据同步）。设计：高频、非分片键、等值/范围查询建 GSI；低频或分片键查询用本地索引。按查询模式与成本权衡。

本地索引低成本但跨分片靠全路由，GSI 用成本换查询效率。按"查询频率 + 是否分片键"取舍，高频非分片键查用 GSI。