mysql Hibernate如何操作_mysql ORM框架原理

MySQL 8 连接需加 allowPublicKeyRetrieval=true；save() 可能立即执行 SQL 而 persist() 延迟至事务提交；LazyInitializationException 主因是 View 层 Session 已关闭；Hibernate 判定 INSERT/UPDATE 依据对象是否在 Session 缓存中（persistent 状态），非主键是否为空。

MySQL + Hibernate 连不上数据库，先查 hibernate.connection.url 格式对不对

最常见的连不上不是密码错，而是 JDBC URL 写成 MySQL 8 之前的格式。MySQL 8 默认启用 caching_sha2_password 插件，老驱动不认，会报 Public Key Retrieval is not allowed 或直接卡在连接超时。

正确写法（MySQL 8.0+ + Hibernate 5.4+）：

hibernate.connection.url=jdbc:mysql://localhost:3306/mydb?useSSL=false&serverTimezone=UTC&allowPublicKeyRetrieval=true&characterEncoding=utf8

• allowPublicKeyRetrieval=true 是关键，不加就拒绝握手
• serverTimezone=UTC 避免时区解析异常（比如报 The server time zone value '……' is unrecognized）
• 用 & 而不是 & —— XML 或 properties 文件里写错会导致参数被截断

save() 和 persist() 看似一样，但 flush 时机决定是否立即发 SQL

两者都把对象变成持久态，但触发 INSERT 的时机不同：前者可能立刻执行 SQL（取决于当前 Session 是否已 flush），后者只保证在事务提交前 INSERT，更轻量。

典型误用场景：循环里反复调用 save()，每轮都可能触发一次 INSERT，性能崩；换成 persist() + 手动 session.flush() 控制节奏更稳。

• save() 返回生成的主键值，persist() 不返回（void）
• 如果 Session 已 dirty（有未刷数据），save() 可能顺带 flush 其他待更新对象，造成意外交互
• JPA 规范只定义 persist()，save() 是 Hibernate 特有 API，跨框架迁移时建议优先用前者

LazyInitializationException 不是配置漏了，而是 Session 在 view 层就关了

报这个错，90% 情况不是 @OneToMany(fetch = FetchType.LAZY) 写错了，而是 Controller 返回 JSON 时，Hibernate 已经关闭 Session，但 Jackson 还在反射 getter 触发代理加载。

解决路径很窄，别试“加 @Transactional 到 service 外层”这种粗暴方案——它会让事务拖到视图渲染完，锁表风险高。

• 最稳：用 @EntityGraph 显式声明需要 JOIN 的关联字段，一次查全
• 次选：DTO 手动拷贝，用 BeanUtils.copyProperties() 或 MapStruct，彻底脱离实体代理
• 禁用：在 application.properties 加 spring.jpa.open-in-view=true —— 它会让 Session 绑定整个 HTTP 请求，掩盖问题但埋下连接泄漏隐患

Hibernate 怎么知道该 UPDATE 还是 INSERT？靠的是对象的「持久化状态」，不是主键空不空

很多人以为 id == null 就 INSERT，id != null 就 UPDATE，这是错觉。真正判断依据是 Session 缓存里有没有这个 id 对应的已加载对象（即 persistent 状态）。你 new 出来一个 id=100 的对象直接 save()，Hibernate 仍当它是 transient，会 INSERT 并忽略你设的 id。

想强制 UPDATE 已存在记录，必须走 merge()：

MyEntity e = new MyEntity(); e.setId(100); e.setName("new name"); session.merge(e); // 查缓存 /DB，有则更新，无则 INSERT

• merge() 返回的是托管对象，原对象仍是 detached，别继续改原对象
• 如果确定主键一定存在且要覆盖，load() + set + update() 更高效（避免 merge 的两次查询）
• 使用 @GeneratedValue(strategy = GenerationType.IDENTITY) 时，merge 无法跳过 INSERT 阶段，因为 ID 必须由 DB 生成

ORM 的核心不是“自动拼 SQL”，而是维护对象状态机与数据库行之间的映射关系。一旦脱离这个视角，所有“为什么 没更新”“怎么多插了一条”的问题都会变成玄学。