控制变量多次测试取平均值可清晰反映插入性能差异：单条无事务约35秒，批量+事务仅1.2秒，差距达28倍；需统一环境、禁用缓存日志、复用连接、清空表重置ID，并用general_log和show processlist验证SQL执行数量与连接活跃时间。

直接写对比测试代码，控制变量、多次运行取平均值，就能清晰看出差距。关键不是“能不能测”，而是怎么让结果真实反映底层差异。

准备统一的测试环境

避免干扰因素，所有测试必须共用同一套基础配置：

• 使用同一个数据库连接（复用 Connection，禁用自动提交）
• 插入同一张表，字段结构固定，不带触发器或外键约束
• JDBC URL 加上关键参数：rewriteBatchedStatements=true（MySQL）或 useServerPrepStmts=true
• 关闭 MyBatis 的二级缓存、禁用日志输出（如 logback 设置 level=OFF）
• 每次测试前清空表并重置自增 ID，确保起始状态一致

实现三类插入方式

每种方式都封装为独立方法，插入相同数量的数据（例如 10000 条），记录 System.nanoTime() 耗时：

• 单条执行（无事务）：循环中每次 new PreparedStatement + executeUpdate，不手动 commit
• 单条执行（显式事务）：setAutoCommit(false)，循环插入后统一 commit
• 批量执行（PreparedStatement.addBatch）：prepareStatement 复用，每 1000 条调用一次 executeBatch，最后 commit

注意：不要混用方式，比如在批量逻辑里穿插 executeUpdate；也不要让单条方式意外开启事务（检查 autocommit 状态）。

跑多轮取平均值并观察指标

单次测试容易受 GC、CPU 抢占等影响，建议每种方式执行 5–7 次：

Java调试

通过 JDWP 实现 Java 远程调试：连接远程 JVM、设置断点、单步执行代码、查看变量值、获取调用栈。适用于需要调试远程 Java 应用、排查运行时状态、追踪代码执行流程的场景。 术语注解 JDWP：Java Debug Wire Protocol，Java 调试有线协议（Java 远程调试底层通信协议） remote JVM：远程 Java 虚拟机 step through code：代码单步调试（步入 / 步过 / 步出调试） inspect variables：变量查看 / 变量检视 stac

下载

• 记录每次的耗时（ms）、JVM 内存峰值（可用 Runtime.getRuntime().maxMemory() 和 totalMemory() 估算）
• 开启 MySQL general_log 或慢日志，确认单条方式真发了 N 条语句，批量方式只发了 ⌈N/1000⌉ 条
• 用 show processlist 观察连接活跃时间，批量方式应明显更短

实测常见结果：10000 条数据下，单条无事务约 35 秒，批量+事务约 1.2 秒——差距可达 28 倍。

用 JMeter 或简单脚本补压测视角

如果想验证并发下的表现，可跳过手写循环，改用工具辅助：

• JMeter 配置 JDBC Request，线程组设 10 用户 × 1000 循环，分别指向不同插入接口
• 写个 Shell 脚本循环调用 Java Main 类，每次传入 mode=single 或 mode=batch 参数
• 配合 Prometheus + Grafana 监控数据库的 TPS、连接数、Innodb_row_lock_time

这样能看到批量操作在高并发时对连接池和锁资源的压力优势。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南