身为一名小小的程序猿，在日常开发中不可以避免的要和where in和like打交道，在大多数情况下我们传的参数不多简单做下单引号、敏感字符转义之后就直接拼进了SQL，执行查询，搞定。若有一天你不可避免的需要提高SQL的查询性能，需要一次性where in 几百、上千、甚至上万条数据时，参数化查询将是必然进行的选择。然而如何实现where in和like的参数化查询，是个让不少人头疼的问题。 where in 的参数化查询实现 首先说一下我们常用的办法，直接拼SQL实现，一般情况下都能满足需要 需要参数化查询时进行的尝试，很显然如下这样执行SQL会报错错误 很显然这样会报错误：在将 varchar 值 '1,2,3,4' 转换成数据类型 int 时失败，因为参数类型为字符串，where in时会把@UserID当做一个字符串来处理，相当于实际执行了如下语句 若执行的语句为字符串类型的，SQL执行不会报错，当然也不会查询出任何结果 这样不会抱任何错误，也查不出想要的结果，因为这个@UserName被当做一个字符串来处理，实际相当于执行如下语句 由此相信大家对于为何简单的where in 传参无法得到正确的结果知道为什么了吧，下面我们来看一看如何实现正确的参数化执行where in，为了真正实现参数化where in 传参，很多淫才想到了各种替代方案 方案1，使用CHARINDEX或like 方法实现参数化查询，毫无疑问，这种方法成功了，而且成功的复用了查询计划，但同时也彻底的让查询索引失效(在此不探讨索引话题)，造成的后果是全表扫描，如果表里数据量很大，百万级、千万级甚至更多，这样的写法将造成灾难性后果；如果数据量比较小、只想借助参数化实现防止SQL注入的话这样写也无可厚非，还是得看具体需求。(不推荐) 方案2 使用exec动态执行SQL，这样的写法毫无疑问是很成功的，而且代码也比较优雅，也起到了防止SQL注入的作用，看上去很完美，不过这种写法和直接拼SQL执行没啥实质性的区别，查询计划没有得到复用，对于性能提升没任何帮助，颇有种脱了裤子放屁的感觉，但也不失为一种解决方案。(不推荐) 方案3 为where in的每一个参数生成一个参数，写法上比较麻烦些，传输的参数个数有限制，最多个，可以根据需要使用此方案(推荐) 方案4 使用临时表实现(也可以使用表变量性能上可能会更加好些)，写法实现上比较繁琐些，可以根据需要写个通用的where in临时表查询的方法，以供不时之需，个人比较推崇这种写法，能够使查询计划得到复用而且对索引也能有效的利用，不过由于需要创建临时表，会带来额外的IO开销，若查询频率很高，每次的数据不多时还是建议使用方案3，若查询数据条数较多，尤其是上千条甚至上万条时，强烈建议使用此方案，可以带来巨大的性能提升(强烈推荐) like参数化查询 like查询根据个人习惯将通配符写到参数值中或在SQL拼接都可，两种方法执行效果一样，在此不在详述 看到Tom.汤和蚊子额的评论 补充了下xml传参和tvp传参，并对6种方案做了个简单总结 Sql Server参数化查询之where in和like实现之xml和DataTable传参 此文章属懒惰的肥兔原创
推荐整理分享SqlServer参数化查询之where in和like实现详解(sql参数化是什么意思)，希望有所帮助，仅作参考，欢迎阅读内容。
文章相关热门搜索词:参数化sql命令,sqlserver参数配置,sqlserver参数化查询慢,sqlserver参数化查询,sql参数化是什么意思,sql语句参数查询,sqlserver参数化查询慢,sqlserver参数化查询,内容如对您有帮助，希望把文章链接给更多的朋友！
SqlServer参数化查询之where in和like实现之xml和DataTable传参介绍 方案5使用xml参数对sqlserverxml类型参数不熟悉的童鞋需要先了解下XQuery概念，这里简单提下XQuery是用来从XML文档查找和提取元素及属性的语言，简单说就
SQLServer中字符串左对齐或右对齐显示的sql语句 知识点：函数replicate以下代码是实现如下功能：declare@sqlvarchar(),--需填充的字符串@charvarchar(4),--填充使用的字符@lenint--填充后的长度select@sql='abc'select@c
将mater库中的系统存储过程批量生成*.sql文件 通用且非常实用 大家都知道系统存储过程是无法用工具导出的（大家可以试试任务生成SQL脚本）因为系统存储过程一般是不让开发人员修改的。需要知识：1、xp_cmdshell
