占位符过多是设计信号而非语法错误，应按业务逻辑自然拆分：主查询保留强过滤条件，弱条件动态拼接或转子查询；IN列表按50～100分批执行；可选条件优先Java层聚合参数并校验后动态构建SQL。
占位符过多本身不是语法错误，而是设计信号：SQL 条件或参数结构可能已超出单一语句的合理表达边界。核心思路不是“强行分段”，而是按业务逻辑、执行意图或数据来源做自然拆分。
按查询意图分离主从语句
比如一个搜索接口同时支持标题模糊、状态筛选、时间范围、多标签匹配——这些条件组合爆炸，硬塞进一个 PreparedStatement 容易失控。可拆成：
- 主查询只保留强过滤字段（如 status = ? AND create_time BETWEEN ? AND ?），用固定占位符
- 弱条件（如标题关键词、标签 ID 列表）改用动态拼接 SQL（在严格校验后），或转为子查询/临时表
- 标签匹配这类“变长数组”，不适用 ? 占位符，应改用 FIND_IN_SET 或 JOIN 关联标签中间表，避免 setArray 或循环 addBatch
用 IN 子句替代多个等值占位符
当需要传入一组 ID（如 id IN (?, ?, ?, ?)），不要手动拼 100 个问号。正确做法是：
- 根据数据库限制（MySQL 默认 max_allowed_packet 和预编译上限），将列表按 50～100 个一批分组
- 每批生成独立的 PreparedStatement，例如 "SELECT * FROM orders WHERE id IN (?, ?, ...)"（49 个 ?）
- 调用时批量 setLong / setString，再 executeQuery
- 合并结果由 Java 层处理，而非依赖数据库 UNION（性能差且难维护）
对可选条件采用 IS NULL 模式统一收口
如果大量字段都是“有则匹配、无则忽略”，与其为每个字段配两个 ?（判断 + 值），不如用更紧凑写法：
立即学习“Java免费学习笔记（深入）”；
- SQL 中统一用 (? IS NULL OR column = ?)，但注意：每个字段仍需 2 个参数，总数翻倍
- 真正减少占位符数量的方式，是提前在 Java 层聚合条件 —— 只把实际非空的字段加入参数列表，动态构建含对应数量 ? 的 SQL 字符串（需确保输入可信，或白名单校验列名）
- 例如：用户只填了 location 和 price_max，则 SQL 为 "WHERE location = ? AND price
批量操作优先走 executeBatch 而非单条多占位符
插入/更新上百条记录时，“一条 SQL 带 100 组 ?”（如 INSERT INTO t VALUES (?,?),(?,?),...）不仅难维护，还容易超长度限制。应改为：
- 复用同一个 PreparedStatement 实例
- 循环调用 setXxx 设置每行数据，再 addBatch()
- 达到阈值（如 1000 条）后 executeBatch() 提交
- 这样 SQL 模板始终简洁（"INSERT INTO t(a,b) VALUES (?,?)"），占位符恒为 2 个
占位符数量本身不是瓶颈，失控的参数管理才是问题源头。重点在于让 SQL 结构贴合真实业务分支，而不是把所有可能性堆进一个语句里。
