当使用 jOOQ 的 batchInsert() 配合 MariaDB 的 AFTER INSERT 触发器时，可能出现仅插入首条记录的异常行为——根本原因并非 jOOQ 逻辑缺陷，而是 MariaDB 官方 JDBC 驱动对批量语句与触发器协同执行的支持不完善。
当使用 jooq 的 `batchinsert()` 配合 mariadb 的 `after insert` 触发器时，可能出现仅插入首条记录的异常行为——根本原因并非 jooq 逻辑缺陷，而是 mariadb 官方 jdbc 驱动对批量语句与触发器协同执行的支持不完善。
在实际开发中，许多团队依赖数据库触发器实现审计日志、历史快照等业务逻辑（如本例中 trig_after_sku_insert 在插入 sku 后自动向 sku_price_history 写入快照）。然而，当结合 jOOQ 的批量操作时，看似正常的代码却悄然“静默失败”：日志显示 batch size 正确（如 Batch size: 3），但只有第一条记录成功落库，其余被忽略，且无任何异常抛出——这种隐蔽性极易导致数据一致性风险。
问题本质在于 JDBC 驱动层对批量语句（PreparedStatement.addBatch() + executeBatch()）与触发器交互的实现差异。MariaDB Connector/J（尤其是 3.x 系列）在处理含 AFTER INSERT 触发器的批量插入时，存在内部状态同步或结果集处理缺陷，导致后续批次未被正确提交或触发器未被逐行触发。而直接使用原生 JDBC 复现该场景（绕过 jOOQ）同样复现问题，即可确认根源不在 jOOQ 的 DSL 层逻辑。
✅ 验证与解决路径如下：
- 隔离验证：先禁用触发器，确认 batchInsert() 行为正常；再通过纯 SQL 手动事务（START TRANSACTION; INSERT ...; INSERT ...; COMMIT;）验证触发器本身无问题——这可排除应用逻辑与 DDL 错误。
- 驱动级排查：将 MariaDB Connector/J 替换为 MySQL Connector/J（8.0+，兼容 JDBC 4.2）。实测表明，切换后 batchInsert() 与触发器可稳定协同工作，所有记录均正确写入主表及历史表。
-
配置建议（Spring Boot application.yml）：
spring: datasource: url: jdbc:mysql://your-rds-endpoint:3306/your_db?useSSL=false&serverTimezone=UTC&allowPublicKeyRetrieval=true driver-class-name: com.mysql.cj.jdbc.Driver # 显式指定 MySQL 驱动（非 MariaDB）
⚠️ 注意事项：
- MySQL Connector/J 对 MariaDB 服务器具备良好兼容性（二者协议高度一致），官方文档明确支持 MariaDB 10.2+；
- 若必须使用 MariaDB 驱动，请升级至最新版（如 3.1.4+），并关注其 GitHub issue #372 等相关修复进展；
- 避免在高并发批量场景下依赖 AFTER INSERT 触发器生成关键业务数据，优先考虑应用层显式写入或数据库物化视图方案，以提升可测试性与可观测性。
综上，此问题本质是 JDBC 驱动与特定数据库特性的兼容性边界问题。面对类似“jOOQ 行为异常”的场景，应遵循「触发器→JDBC→jOOQ」由底层向上逐层排查的思路，而非默认归因于 ORM/DSL 工具本身。
