这个得看你怎么用的 如果说是用在where 后面 例如 where convert(.....)=....的，那效率低很正常。因为这杨如果日期字段有索引，那就用不上了
convert ---强制类型转换函数，没了，就这些 被这个函数坑害了。查询效率超级底----这个问题，应该跟这个函数的关系不是很大，主要问题应该是你的SQL语句的写法问题，请检查一下你的where条件是否含有下面的情况： 1、避免在 where 子句中对字段进行 null 值判断。 2、应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。优化器将无法通过索引来确定将要命中的行数,因此需要搜索该表的所有行。 3、应尽量避免在 where 子句中使用 or 来连接条件。 4、对于连续的数值，能用 between 就不要用 in 。 5、避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。 6、避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。 7、不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引
2 5 6 7 全满足我死的好惨 吼吼，既然如此，先看看想办法看看能不能把你满足2、5、6、7的地方改掉吧，然后再看看执行计划，看看有没有需要调整索引的地方已经调整了。速度超棒的。终于秒显示了呵呵。不到一秒就显示了对了。顺便问个怎么才能看sql语句精确的执行时间。右下角的执行时间只到秒，我想看到毫秒的 set statistics time on ; 你的语句 set statistics time off;
你如果那个列是时间字段，没有必要非要转成2014-05-08这样的日期格式，即使是时间格式也是可以的。直接用：列 between '2014-01-01' and '2014-03-01'这样的写法。
你如果那个列是时间字段，没有必要非要转成2014-05-08这样的日期格式，即使是时间格式也是可以的。直接用：列 between '2014-01-01' and '2014-03-01'这样的写法。 恩现在就是改成这种写法 问个小问题 我数据库存储的时间都是 2014-03-01 05：06：01 这样的 你这个能查到最后一天最后一秒么
2 5 6 7 全满足我死的好惨 吼吼，既然如此，先看看想办法看看能不能把你满足2、5、6、7的地方改掉吧，然后再看看执行计划，看看有没有需要调整索引的地方已经调整了。速度超棒的。终于秒显示了呵呵。不到一秒就显示了对了。顺便问个怎么才能看sql语句精确的执行时间。右下角的执行时间只到秒，我想看到毫秒的 set statistics time on ; 你的语句 set statistics time off; 新技能get，刚才试了一下 存储过程也可以用这个哈哈哈。新技能！
where convert(.....)=....的，那效率低很正常。因为这杨如果日期字段有索引，那就用不上了
被这个函数坑害了。查询效率超级底----这个问题，应该跟这个函数的关系不是很大，主要问题应该是你的SQL语句的写法问题，请检查一下你的where条件是否含有下面的情况：
1、避免在 where 子句中对字段进行 null 值判断。
2、应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。优化器将无法通过索引来确定将要命中的行数,因此需要搜索该表的所有行。
3、应尽量避免在 where 子句中使用 or 来连接条件。
4、对于连续的数值，能用 between 就不要用 in 。
5、避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。
6、避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。
7、不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引
话说为什么我的帖子在c#水区挪到sql技术区了200分是散的啊！！！
话说为什么我的帖子在c#水区挪到sql技术区了200分是散的啊！！！因为你问的是SQL Server的东西，所以曹版主帮你一过来了。常规建议的确是要复合SARG写法，不过具体问题具体分析
话说为什么我的帖子在c#水区挪到sql技术区了200分是散的啊！！！因为你问的是SQL Server的东西，所以曹版主帮你一过来了。常规建议的确是要复合SARG写法，不过具体问题具体分析
就是把 有个表里面的数据 按照10W条来算吧 时间字段的类型是 datetime 看完你的内个博文之后我觉得内个表类型改成smalldatetime 只需要精确到分钟都够够的了。然后把我查询是 查询某一个时间段的内的数据 之前写法是
convert(varchar(10),列,120)>='2014-01-01' and convert(varchar(10),列,120)<='2014-03-01'
所以才想问这个函数为什么这么慢。
现在的写法是
列 between '2014-01-01' and '2014-03-01'
看了下内个执行发现就是在全局聚合索引耽误的时间和效率性能。
水区吐槽。。被老曹认为是技术贴。。愁死人了
吼吼，既然如此，先看看想办法看看能不能把你满足2、5、6、7的地方改掉吧，然后再看看执行计划，看看有没有需要调整索引的地方已经调整了。速度超棒的。终于秒显示了呵呵。不到一秒就显示了对了。顺便问个怎么才能看sql语句精确的执行时间。右下角的执行时间只到秒，我想看到毫秒的
吼吼，既然如此，先看看想办法看看能不能把你满足2、5、6、7的地方改掉吧，然后再看看执行计划，看看有没有需要调整索引的地方已经调整了。速度超棒的。终于秒显示了呵呵。不到一秒就显示了对了。顺便问个怎么才能看sql语句精确的执行时间。右下角的执行时间只到秒，我想看到毫秒的
set statistics time on ;
你的语句
set statistics time off;
吼吼，既然如此，先看看想办法看看能不能把你满足2、5、6、7的地方改掉吧，然后再看看执行计划，看看有没有需要调整索引的地方已经调整了。速度超棒的。终于秒显示了呵呵。不到一秒就显示了对了。顺便问个怎么才能看sql语句精确的执行时间。右下角的执行时间只到秒，我想看到毫秒的
额，问题解决了就OK了。呵呵，以后写语句注意那些会导致不走索引的where条件呗
你要看的执行时间，21楼，版主有给你回答了。
要就给你一份
恩现在就是改成这种写法 问个小问题 我数据库存储的时间都是 2014-03-01 05：06：01 这样的 你这个能查到最后一天最后一秒么
吼吼，既然如此，先看看想办法看看能不能把你满足2、5、6、7的地方改掉吧，然后再看看执行计划，看看有没有需要调整索引的地方已经调整了。速度超棒的。终于秒显示了呵呵。不到一秒就显示了对了。顺便问个怎么才能看sql语句精确的执行时间。右下角的执行时间只到秒，我想看到毫秒的
set statistics time on ;
你的语句
set statistics time off;
新技能get，刚才试了一下 存储过程也可以用这个哈哈哈。新技能！