模糊查询的参数嗅探

来源：互联网发布：解析域名多久生效编辑：程序博客网时间：2024/06/05 14:41

表 t , 有复合索引 ix_t_p1_p2，p1 的筛选性不是很高。

无论加不加 option(recompile) , 执行计划走的都是索引查找，但不加时，因为无法准确识别参数中的%，导致执行计划错误。

这个不用 option(recompile) 就无解了。因为毕竟是传入值，不能直接拼SQL（担心有注入风险）。

试过末尾添加：

OPTION (OPTIMIZE FOR (@p0=N'%15673618567%',@1=N'JK523000'))

并没有优化效果。

如果去掉复合索引，能快起来，但担心这个索引在其它地方有用到。

最终的方案还是加 option(recompile),。

需要注意的是，要重现程序里的SQL, 必须用 sp_executesql

优化前优化后

set statistics io onset statistics time ondeclare @p0 nvarchar(8),@p1 nvarchar(13),@sql nvarchar(max)select @p0=N'%15673618567%',@p1=N'JK523000'SET @sql='SELECT * FROM dbo.[t] WHERE 1 = 1 AND [p0] = @p0AND [p1] LIKE @p1'EXEC sp_executesql @sql,N'@p0 nvarchar(8),@p1 nvarchar(13)',@p0,@1

set statistics io onset statistics time ondeclare @p0 nvarchar(8),@p1 nvarchar(13),@sql nvarchar(max)select @p0=N'%15673618567%',@p1=N'JK523000'SET @sql='SELECT * FROM dbo.[t] WHERE 1 = 1 AND [p0] = @p0AND [p1] LIKE @p1option( recompile )'EXEC sp_executesql @sql,N'@p0 nvarchar(8),@p1 nvarchar(13)',@p0,@1

(1 行受影响)表 'user_app_data'。扫描计数 1，逻辑读取 21356 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。 SQL Server 执行时间:   CPU 时间 = 10670 毫秒，占用时间 = 10901 毫秒。 SQL Server 执行时间:   CPU 时间 = 10670 毫秒，占用时间 = 10902 毫秒。

(1 行受影响)表 'user_app_data'。扫描计数 17，逻辑读取 22223 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。表 'Worktable'。扫描计数 0，逻辑读取 0 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。表 'Worktable'。扫描计数 0，逻辑读取 0 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。 SQL Server 执行时间:   CPU 时间 = 11559 毫秒，占用时间 = 772 毫秒。 SQL Server 执行时间:   CPU 时间 = 11575 毫秒，占用时间 = 783 毫秒。

总时间：10.9 s总时间：0.783 s

不加 option(recompile) 的执行计划：

添加 option(recompile) 的执行计划：

阅读全文

0 0