Oracle JDBC连接串必须加oracle.net.CONNECT_TIMEOUT、oracle.jdbc.ReadTimeout、oracle.jdbc.defaultRowPrefetch三个参数，分别控制DNS解析超时、查询读取超时和行预取数量，缺一导致连接池假死、超时误报或ORA-01017认证失败。
Oracle JDBC连接串里必须加哪些关键参数
不加特定参数，jmeter压测时会遇到连接池假死、超时误报、甚至 oracle 报 ora-01017（看似密码错，实为认证超时）。核心是控制连接生命周期和协议行为。
-
oracle.net.CONNECT_TIMEOUT=3000：单位毫秒，避免 DNS 解析慢拖垮线程，尤其在容器或云环境 -
oracle.jdbc.ReadTimeout=10000：防止长查询卡住整个线程，JMeter 线程池无法回收 -
oracle.jdbc.defaultRowPrefetch=50：减少 round-trip 次数，对SELECT多的场景吞吐提升明显（但别设太大，内存吃紧） - 去掉
oracle.jdbc.ThinDriver显式指定——JDBC 4.0+ 会自动加载，硬写反而在 JDK 11+ 上触发ClassNotFoundException
JMeter JDBC Request 中的 SQL 写法陷阱
直接贴 SELECT * FROM orders WHERE id = ? 看似没问题，但 Oracle 对绑定变量敏感，稍不注意就让执行计划失效，压测结果失真。
- 所有变量必须用
?占位，不能拼字符串——否则 JMeter 不会复用 PreparedStatement，Oracle 会为每条语句硬解析 - 避免
WHERE status IN (${status_list})这类动态列表：JMeter 不支持数组传参，Oracle 会退化成全表扫描 - 写 DML 时记得加
RETURNING子句（如INSERT INTO log VALUES (?) RETURNING id INTO ?），否则 JMeter 拿不到生成主键，后续请求断链 - 批量操作别用多条
INSERT，改用ADD BATCH+EXECUTE BATCH模式，否则网络开销翻 N 倍
Oracle 数据库端要同步调什么
JMeter 跑得再猛，如果 Oracle 实例没配好，瓶颈永远卡在服务端。重点不是加大 SGA，而是让并发真正落地。
- 确认
processes参数 ≥ JMeter 最大线程数 × 1.5（比如 JMeter 设 200 线程，processes至少 300） - 禁用
SQL Tuning Advisor自动任务：EXEC DBMS_AUTO_TASK_ADMIN.DISABLE('sql tuning advisor');，否则压测中后台任务抢资源 - 临时表空间必须是
LOCAL管理且有足够UNDO_RETENTION（建议 ≥ 1800），否则高并发ORDER BY或哈希连接会报ORA-01555 - 检查
v$session中是否存在大量SQL*Net message from client等待——说明 JDBC 没设超时，客户端在空等
怎么判断压测结果可信
看到 QPS 上万就以为性能 OK？Oracle 的等待事件才是真相。JMeter 报表只是表象，v$active_session_history 才是证据链。
- 别只看 JMeter 的
90% Line，查SELECT event, COUNT(*) FROM v$active_session_history WHERE sample_time > SYSDATE - 1/1440 GROUP BY event ORDER BY 2 DESC，如果前两名是enq: TX - row lock contention或db file sequential read，说明业务逻辑或索引有问题，不是数据库不行 - JMeter 的
Response Time包含网络 RTT，Oracle 侧用DB CPU+db file scattered read时间对比，差值超过 20ms 就该查网络或 JDBC 驱动版本 - 用
ALTER SYSTEM FLUSH SHARED_POOL清一次缓存再跑第二轮——避免第一次冷启污染结果，但别频繁清，否则测的是解析性能而非执行性能
真实压测里最常漏掉的是 Oracle 客户端字符集和 NLS 设置匹配。JMeter 启动脚本里没加 -Dfile.encoding=UTF-8，又连了中文字段的表，ORA-01401 和乱码会交替出现，查半天发现是编码没对齐。
立即学习“Java免费学习笔记（深入）”；
