JDBC本身不提供分布式主键生成能力，仅支持单库自增主键的获取；分库分表下必须由应用层或ShardingSphere等中间件前置生成全局唯一ID（如Snowflake），再通过JDBC显式插入，且表字段不可设AUTO_INCREMENT。
JDBC 本身是数据库访问规范，不提供分布式主键生成能力。它只负责执行 SQL、传递参数、获取结果——包括获取数据库生成的主键（如 getGeneratedKeys()），但这个能力仅适用于单库单表的自增主键场景。在真正分布式环境（如分库分表）下，JDBC 无法直接解决主键唯一性问题，必须配合外部策略。关键在于：JDBC 是执行者，不是决策者；主键逻辑必须前置到应用层或中间件中。
下面从实际协作角度讲清楚怎么处理：
JDBC 不参与分布式 ID 生成，但要配合好
- JDBC 的
getGeneratedKeys()只能拿到当前数据库实例返回的自增 ID，比如 MySQL 的LAST_INSERT_ID()。一旦分库，各库 ID 独立，必然冲突。 - 所以在分库分表架构中，不能依赖 JDBC + 数据库 AUTO_INCREMENT 来生成主键，否则全局不唯一。
- 正确做法是：主键值由应用层（或中间件）提前生成，再通过 JDBC 插入时显式传入 —— 此时 JDBC 只是“把已算好的 ID 写进去”。
应用层生成 ID 后，用 JDBC 安全插入
你需要自己生成 ID（例如雪花算法），再用标准 JDBC 插入：
// 1. 先生成分布式 ID（例如用 Snowflake）
long orderId = snowflakeIdGenerator.nextId();
// 2. 使用 PreparedStatement 显式设置主键字段
String sql = "INSERT INTO t_order (order_id, user_id, amount) VALUES (?, ?, ?)";
PreparedStatement ps = connection.prepareStatement(sql);
ps.setLong(1, orderId); // 主键不再靠数据库生成
ps.setLong(2, 1001);
ps.setBigDecimal(3, new BigDecimal("99.90"));
ps.executeUpdate();⚠️ 注意：此时表结构中 order_id 字段不能加 AUTO_INCREMENT，否则 MySQL 会忽略你传的值，强行自增，导致逻辑错乱。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
如果用 ShardingSphere-JDBC，JDBC 行为被自动增强
ShardingSphere 在 JDBC 驱动之上做了封装，它会在执行 executeUpdate() 前拦截 SQL，自动注入主键值：
- 你配置了
key-generator.type=SNOWFLAKE和worker.id - 实体对象中
order_id为空（null 或 0，取决于类型） - ShardingSphere 就会调用雪花算法生成 ID，并拼进 INSERT SQL
- 最终 JDBC 执行的是带完整主键值的语句，全程无感
但前提是：
- 不要在 Java 对象里提前给主键字段赋值（否则跳过生成逻辑）
- 表结构中主键字段不能设
AUTO_INCREMENT -
key-generator.column必须与实体字段名、SQL 字段名严格一致
避免常见陷阱
- ❌ 在 MyBatis 中用
@TableId(type = IdType.AUTO)注解 → 强制走数据库自增，和分库分表冲突 - ❌ 插入前手动
SELECT MAX(id)+1→ 跨库不适用，且高并发下重复 - ❌ 把 UUID 当主键直接塞进
BIGINT字段 → 类型不匹配，报错或截断 - ❌ 多服务共用同一个
worker.id→ 雪花 ID 重复风险极高
主键生成这件事，本质是业务架构决策。JDBC 只管“怎么写”，不管“写什么”。真正要花精力设计的，是 ID 生成器的选型（Snowflake / CosId / TinyID）、机器 ID 分配、时钟回拨应对、以及和 ORM 框架的协同方式。
