Java数据库交互优化核心是“怎么选+怎么传+怎么映射”：字段类型需严格对齐，JDBC优先用原生setXxx()方法，ORM慎用包装类，DAO层避免无谓装箱。
Java 中基本类型和包装类本身不直接“存储在数据库中”，它们是 JVM 内存中的数据载体；真正影响数据库交互效率的是：你如何用它们建模业务数据、映射到 SQL 类型、传递给 JDBC，并避免隐式开销。优化核心不是“怎么存”，而是“怎么选 + 怎么传 + 怎么映射”。
数据库字段类型决定 Java 端基本类型选择
映射应严格对齐数据库定义的精度与范围，避免无谓扩容或截断：
- MySQL
TINYINT(1)或SMALLINT→ Java 用byte或short，而非默认int；节省内存且语义准确 - PostgreSQL
NUMERIC(10,2)（如金额）→ Java 必须用BigDecimal，不可用float/double（精度丢失风险） - Oracle
CHAR(1)表示状态（Y/N）→ Java 用char或String，但若仅作布尔判断，可统一转为boolean字段（注意空值处理） - 主键是
BIGINT→ Java 用long；若是 UUID 字符串，则用String，但需意识到它比long多占 3–4 倍内存（如 "123e4567-e89b-12d3-a456-426614174000" 占约 36 字节）
JDBC 参数绑定优先使用基本类型对应方法
CallableStatement 和 PreparedStatement 的 setXxx() 方法有明确类型重载，应匹配使用，避免装箱和隐式转换：
- 设整数参数：用
setInt(int parameterIndex, int x)，而非setObject(..., Integer.valueOf(x)) - 设布尔值：用
setBoolean(int parameterIndex, boolean x)，不是setObject(..., Boolean.TRUE) - 设时间戳：用
setTimestamp(int parameterIndex, Timestamp x)，而非setObject(..., new Date())（后者触发额外类型推断） - 批量插入时，原生数组（
int[]）配合setInt()循环比List<integer></integer>更快更省内存
ORM 场景下慎用包装类字段，尤其做条件查询时
JPA/Hibernate 实体中，用 Integer id 虽支持 null，但会带来三重隐患：
立即学习“Java免费学习笔记（深入）”；
-
内存浪费：每个
Integer对象至少 16 字节（对象头 + value），而int仅 4 字节；万级对象就多占上百 KB -
查询歧义：
@Column(name = "status") private Integer status;—— 当数据库值为NULL，Java 中是null；但若用int status = 0，则无法区分“未设置”和“值为 0” -
SQL 生成风险：某些 ORM 在
WHERE status = ?绑定null时，可能生成WHERE status IS NULL（正确），也可能静默跳过条件（错误）；而int字段无法为 null，逻辑更确定 - 建议：主键/非空字段用基本类型（
long id）；允许为空的业务字段（如discountRate）才用Double或Integer，并在注解中标明@Column(nullable = true)
避免在 DAO 层做无意义的装箱/拆箱流转
从 ResultSet 提取数据后，不要立刻包装再传出；保持原始类型向上传递：
- ❌ 错误写法：
return new User(id, Integer.valueOf(rs.getInt("age")), rs.getString("name")); - ✅ 正确写法：
return new User(id, rs.getInt("age"), rs.getString("name"));（假设 age 是NOT NULL TINYINT） - 批量结果集处理时，用
rs.getInt()直接填入int[]数组，比塞进List<integer></integer>再转数组快 3–5 倍，GC 压力更低 - 若需兼容 null（如
age允许为空），用rs.getObject("age", Integer.class)（JDBC 4.2+），它返回Integer但由驱动内部优化，比rs.getInt()+ 手动判wasNull()更简洁安全
