数据库本身不主动配合分库分表，真正配合体现在数据源配置、分片规则定义、SQL行为约束和运维协同四环节：需显式声明物理数据源并统一基础参数，分片键须高基数且查询高频，SQL须规避全库扫描与跨库JOIN，运维需逐实例管理备份、慢查与扩容。
Java 微服务架构中，数据库本身不主动“配合”分库分表，而是通过中间件（如 ShardingSphere-JDBC）在应用层与数据库之间架设一层透明路由和改写能力。真正的配合体现在数据源配置、分片规则定义、SQL 行为约束和运维协同四个关键环节。
数据源需按物理拓扑显式声明
数据库实例必须提前准备就绪，不能由框架自动创建。ShardingSphere-JDBC 要求你在 Spring Boot 配置中明确列出所有真实数据源（如 ds-0、ds-1），包括连接地址、账号密码、连接池参数等：
- 每个数据源对应一个独立的 MySQL 实例或逻辑库，不能共用同一库名
- 建议统一字符集（utf8mb4）、时区（UTC+8）、事务隔离级别（READ_COMMITTED）
- 避免跨数据源使用 AUTO_INCREMENT 主键，应改用分布式 ID（如 Snowflake）
分片规则必须与业务模型对齐
数据库表结构本身无需修改，但分片策略必须基于真实字段和查询模式设计：
- 选好分片键：优先用高频查询条件字段（如 user_id、order_no），且具备高基数、低变更率
- 避免全库扫描：WHERE 条件中不含分片键的 SQL 会路由到所有节点，性能陡降
- JOIN 有约束：仅支持分片键完全一致的单库内关联；跨库 JOIN 需拆成多次查询+内存合并
SQL 写法要适配分片语义
数据库执行的是改写后的物理 SQL，因此原始逻辑 SQL 必须符合分片中间件的解析边界：
立即学习“Java免费学习笔记（深入）”；
- 禁用非标准函数：如 NOW()、UUID() 在部分版本中无法正确下推
- 慎用子查询：尤其是含聚合或 LIMIT 的子查询，可能触发全路由
- INSERT 必须带列名：避免因表结构扩展导致字段错位，影响路由准确性
运维需同步管理多套数据库实例
分库分表后，数据库不再是“一个整体”，而是一组协同工作的节点：
- 备份与恢复需按数据源逐个执行，不可依赖单库全量 dump
- 慢 SQL 定位要结合 ShardingSphere 的 SQL 解析日志 + 各库的 slow_log
- 扩容时需预建新库/表，并通过分片算法平滑迁移数据（如从 mod 4 升级为 mod 8）
