"In"话语对执行效率的影响？
"In"语句对执行效率的影响？？？
SQL语句中的In 会使 SQLServer表中的索引失效。
比如：PointCode字段有一组值“A0001、A0002、A0003、A0004、A0005”等。
如果要取出一组数据，是应该用C#循环取数据，还是用SQL的In语句一次性读取数据。这两个方法那个效率比较高？？？
PointCode in (A0001、A0002、A0003、A0004、A0005)
------解决思路----------------------
不用In也可以用Union，不过说实在的，一般来说用in也无所谓的
至于你说的两种方法，100% in效率高，因为一个是一次返回，一个是反复请求，存在反复的数据库连接
------解决思路----------------------
当然是一次性取效率高
索引失效也只是相比使用索引效率低
但是毕竟是数据服务器在搜索,而不是先将上千万数据通信到客户机,再使用客户机那点可怜的配置去循环匹配
------解决思路----------------------
至于用=连接,反复获取
还要看你到底要取几条数据吧,这个也不是很确定,需要测试
如果你只取2条数据,可能反复取2次比执行一次in效率还高一点点
如果你取100条呢?那么必然是一次性取出效率高,而不是反复建立连接,反复通信
------解决思路----------------------
SQL Server应该是可以优化 In 的，只要你建立了正确的索引，那么它应该完全等价于（你举得例子少了单引号）
where PointCode ='A0001' or PointCode ='A0002' or PointCode ='A0003' or PointCode ='A0004' or PointCode ='A0005'
你可以使用SQL Server管理客户端的分析器工具查看一下是否用到索引。如果没有，那么就直接写成这种表达式（而不是in）就行了。不过SQL Server应该是优化了这个的，应该不会使索引失效。
你说“ In 会使 SQLServer表中的索引失效”，这个出自哪一个文章？是否是针对SQL Server单独进行了“例外”考虑？
------解决思路----------------------
伪命题= =
------解决思路----------------------
这问题其实正规的态度是不给答案，因为其实性能优化问题是的确要有性能问题才有优化问题
所以，不是电视上告诉你“吃盐有害健康”“吃醋伤肺”，你就真滴不吃盐，不吃醋了！
所以我滴态度就是，如果你的项目里，没有实际证据说这里有问题，那么请你把博客园那些条条框框全忘干净
另外博客园那些东西也不是真理，你必须实际测量在谈优化，比如表扫描，不是博客园告诉这样要如何，那样要如何，而是你实际证明这样ok，那样不ok。同样不是博客园告诉你的left join就一定比什么 in，like高效，我实际证明过用like不到10毫秒，用left join要8分钟滴情况！！
------解决思路----------------------
不要用not in就行了。in是可以索引的
------解决思路----------------------
反正按我的习惯,没有出现性能问题,就根本不考虑性能问题
数据库里一共就12条数据,管你用=,用in还是用like,能有多大区别
SQL语句中的In 会使 SQLServer表中的索引失效。
比如：PointCode字段有一组值“A0001、A0002、A0003、A0004、A0005”等。
如果要取出一组数据，是应该用C#循环取数据，还是用SQL的In语句一次性读取数据。这两个方法那个效率比较高？？？
PointCode in (A0001、A0002、A0003、A0004、A0005)
------解决思路----------------------
不用In也可以用Union，不过说实在的，一般来说用in也无所谓的
至于你说的两种方法，100% in效率高，因为一个是一次返回，一个是反复请求，存在反复的数据库连接
------解决思路----------------------
当然是一次性取效率高
索引失效也只是相比使用索引效率低
但是毕竟是数据服务器在搜索,而不是先将上千万数据通信到客户机,再使用客户机那点可怜的配置去循环匹配
------解决思路----------------------
至于用=连接,反复获取
还要看你到底要取几条数据吧,这个也不是很确定,需要测试
如果你只取2条数据,可能反复取2次比执行一次in效率还高一点点
如果你取100条呢?那么必然是一次性取出效率高,而不是反复建立连接,反复通信
------解决思路----------------------
SQL Server应该是可以优化 In 的，只要你建立了正确的索引，那么它应该完全等价于（你举得例子少了单引号）
where PointCode ='A0001' or PointCode ='A0002' or PointCode ='A0003' or PointCode ='A0004' or PointCode ='A0005'
你可以使用SQL Server管理客户端的分析器工具查看一下是否用到索引。如果没有，那么就直接写成这种表达式（而不是in）就行了。不过SQL Server应该是优化了这个的，应该不会使索引失效。
你说“ In 会使 SQLServer表中的索引失效”，这个出自哪一个文章？是否是针对SQL Server单独进行了“例外”考虑？
------解决思路----------------------
伪命题= =
------解决思路----------------------
这问题其实正规的态度是不给答案，因为其实性能优化问题是的确要有性能问题才有优化问题
所以，不是电视上告诉你“吃盐有害健康”“吃醋伤肺”，你就真滴不吃盐，不吃醋了！
所以我滴态度就是，如果你的项目里，没有实际证据说这里有问题，那么请你把博客园那些条条框框全忘干净
另外博客园那些东西也不是真理，你必须实际测量在谈优化，比如表扫描，不是博客园告诉这样要如何，那样要如何，而是你实际证明这样ok，那样不ok。同样不是博客园告诉你的left join就一定比什么 in，like高效，我实际证明过用like不到10毫秒，用left join要8分钟滴情况！！
------解决思路----------------------
不要用not in就行了。in是可以索引的
------解决思路----------------------
反正按我的习惯,没有出现性能问题,就根本不考虑性能问题
数据库里一共就12条数据,管你用=,用in还是用like,能有多大区别