为何Hibernate中setParameter+openjson比setParameterList提升SQL Server查询性能？

第一种方法（setParameterList）的性能瓶颈 #

• SQL编译与执行计划复用问题：用setParameterList传入2000个参数时，Hibernate会生成WHERE id IN (?, ?, ?, ...)格式的SQL，包含2000个占位符。SQL Server每次执行这类SQL时，因参数数量（或值分布）变化，无法复用已有执行计划，必须重新解析、编译整个语句——这一步在参数量大时开销极大，是超时的核心原因之一。
• 参数数量临界值的额外开销：SQL Server单个查询的参数上限是2100个，2000个参数刚好接近阈值，数据库处理这类“接近上限”的参数列表时，内部校验、资源分配的成本会显著上升。
• 低效的执行计划选择：面对超长IN子句，SQL Server查询优化器可能误判数据分布，比如放弃id列的索引转而选择全表扫描——优化器会认为IN子句覆盖范围太广，索引查找成本更高，直接导致查询耗时飙升。
• 网络与参数处理开销：2000个独立参数需要JDBC驱动逐个与数据库交互，包括类型校验、序列化、传输，累计开销远大于单个JSON字符串的传输。

第二种方法（OPENJSON）的性能优势 #

• 固定SQL与执行计划复用：无论传入多少个ID，SQL语句都是固定的（仅一个:listIds占位符），SQL Server只需编译一次，后续执行直接复用缓存的执行计划，省去大量重复编译时间。
• 高效的批量数据解析：OPENJSON是SQL Server原生优化的函数，专门用于快速将JSON数组转换为关系表结构。它处理JSON数组时采用批量操作，内部实现比逐个解析IN子句参数高效得多，转换后的结果可直接与sample_table的id列关联，完美利用索引。
• 简化参数传输：仅需传递一个JSON字符串参数，JDBC与数据库间的参数交互成本大幅降低，避免了大量小参数的传输开销。
• 避开参数数量限制：无论传入多少个ID，都只占用一个参数位置，完全不会触及SQL Server的参数数量上限，也不会触发因参数数量变化导致的异常开销。

内容的提问来源于stack exchange，提问作者jk101