再发两个SQL语句效率，附执行时间图selectid,title from info where cityid11 order by id descselectid,t
再发两个SQL语句效率，附执行时间图
select id,title from info where cityid=11 order by id desc
select id,title from info where substring(city,1,2)='11' order by id desc
其中cityID为INT数据类型 city为varchar数据类型
已经发过一个帖子，大家都认为第一个快，我也这么认为，可是我把city和CITYID都建索引后大家自己看结果吧
结果是差不多，甚至第二个稍快
我想问的是为什么会这样?请懂得索引的高手支招？
[解决办法]
大哥，虽然不懂 顶一下
[解决办法]
用的测试工具?很想用下
[解决办法]
为什么9和8的差别那么大？你的测试环境是独立的吗？最好不要有其他资源占用，还有你的测试平台是什么？1一定比2块，2和没有索引是一样的，另外，你的数据量多少?
[解决办法]
你能给我点实验数据和表结构吗。
欢迎加入MSN群：group197007@msnzone.cn
[解决办法]
LZ用什么测试的？？
[解决办法]
substring(city,1,2)='11' 不是导致行计算吗？根本用不上索引呀，
LZ 给个 city 非索引的 test 再看看
[解决办法]
呵呵，楼主先插入几十万条数据在测试吧？
用sql server profiler测就可以。
[解决办法]
[解决办法]这个跟你的SQL 的原理有关
SQL会将一些需要编译，优化的语句进行缓存，而简单的SQL语句则不做处理
第一个SQL语句直接使用的是CityID ，这样的简单语句在SQL中属于直接就可以执行的，无需缓存，因此SQL会直接扫描索引来直接加载行。
而第二个语句中带有Substring语句，这样的语句很明显是需要占用cpu来计算的，因此在对此语句进行预编译以后，SQL会将该语句加载至缓存，以便下次使用的时候直接从内存读取，不用再次编译，所以性能会有所提高。
换句话说，第二种情况之所以会快是因为缓存的原因，如果不怕麻烦你可以每次从新启动SQL服务，或者执行SQL语句之间的间隔时间长一些，就会发现不一样的结果
而且你上面的测试只是显示出了从客户端到服务端的一些时间信息，如果你在服务器上用Profiler工具检测CPU ，IO读取等等信息的话，应该更为准确
以上根据SQL的原理来解释，实际结果以Profiler工具为准，记得保证没有缓存因素在内。
[解决办法]lz有没有把查询缓存关掉呢？
不关掉查询缓存，测试的结果都是可笑的。
[解决办法]sql2005没有用过 不知道效果如何！
[解决办法]测试不懂，学习
[解决办法]mark
[解决办法]收藏先
[解决办法]先关注一下
[解决办法]几乎确定？从语句上看，如果索引键的ok
第一个百分百的快，第二个有没有索引都没用
[解决办法]改天看
[解决办法]MARK
[解决办法]同意樓上的說法﹐一個 field 盡管有建立index,但該field在where 中套用了函數﹐index就無效
[解决办法]是不是测试的有问题，数据量大的时候，第二个明显就慢！
[解决办法]没搞过测试,不过数据量小的时候,测试结果很难说准!
[解决办法]Mark!
[解决办法]踩踩
[解决办法]不懂。。 关注下。。
------解决方案--------------------
请问查询缓存怎么关掉？什么是查询缓存?
[解决办法]关注
[解决办法][解决办法]这个是我的测试结果，
数据10万条。
第2个是第一个的4-5倍。
[解决办法]发展方向 努力学习中
[解决办法]不太可能
varchar 计算列 还能快？
[解决办法][解决办法]select id,title from info where cityid=11 order by id desc
select id,title from info where city like '11%' order by id desc
應該是第一個快,第二個改為以上應該會更快!substring()會導致無法使用索引
[解决办法][解决办法]学习了...
[解决办法] 学习测试中.
[解决办法]sql2005还没用
[解决办法](1).
select id,title from info where cityid=11 order by id desc
返回8万多条记录，所以就算是cityid上建有索引，优化器也不可能选择它，因为要搭配Bookmark LoopUp操作去取title跟id,这样的随机IO太昂贵了，还不如Clustered Index scan成本低, 所以这里应该是一个Clustered Index scan的操作
建议CityID的索引这么建:
Create index idx_Name ON Info (CityID) INCLUDE (id,title)
(2).
select id,title from info where substring(city,1,2)='11' order by id desc
这个不用说，大家都知道索引用不上,同样是一个Clustered index scan.
[解决办法]remark
[解决办法] UP 学习了
[解决办法]ding!
[解决办法]up
[解决办法]能把测试环境 和 一些详细的参数描述下吗？
[解决办法]ding
[解决办法][解决办法]本来就差不多呀,因为这样萦引都用上了!!!
[解决办法]收藏,再学习,提高
[解决办法]学习，不要求记住（有可能错），学习一下学习方法.
[解决办法]还没有详细研究过。
[解决办法]学习
[解决办法]支持！学习中，虽然不太懂！高手过招！
[解决办法]
我路过这里帮你顶下
[解决办法]
Mark
[解决办法]
学习。。
[解决办法]
我也试试看
[解决办法]
有时间也测试一下...
[解决办法]
mark...
[解决办法]
第一个语句用的是index seek, 第二个语句用的是index scan.
区别就是一个是直接在索引上定位,一个要扫描整个索引.
表扫描?基本上不会.除非这个表很小.
[解决办法]
mark
[解决办法]
[解决办法]学习一下,还不知道如何使用这个工具
[解决办法]纯学习
[解决办法]学习收藏一下了
[解决办法]你跑一下 执行计划 看看！那里应该由你要的答案
你的索引是desc 得的吗? 如果是ASC 的索引 且数据量不大 那就很有可能 第二条快!
建议搂住用SQL2000的话 索引优化向导跑一下他会提示您建什么样子的索引！ 很可能你索引不合适所以造成这个状态！
[解决办法]第二次要清一下缓存
另外cityid 是不是没有 11....的纪录?
[解决办法]UP
[解决办法]索引搜索并不是等效率的,我也总认为运算和不需要运算肯定是不需要运算的快.
int类型和varchar类型的存储大小不同,而每一个页面都是固定大小,因此两个索引存储所耗用的页面数不同,因此在扫描的时候所花的时间一定是有区别的.
具体我也说不清楚,我只能想到这方面的因素了.
[解决办法]学习下
[解决办法]mark
[解决办法]不錯。
[解决办法]这个试验似乎说明不了太大的问题^^^^^^
命中的结果集有差异将会导致,执行计划有差异,甚至是取数据的物理磁盘页面也有差异
所以看起来用到函数和没有用到函数的相差不大
建议楼主重新设计一个试验:使两者命中的行数一致再看结果!
PS:楼主的测试软件再哪搞了^能否提供下!
[解决办法]我要崩溃了...
这几天写的东西，都对性能要求比较高，我快崩溃了，哎~
[解决办法]mark
[解决办法]你建了几个索引，我想你的索引建的不合理
[解决办法]原理问题
[解决办法]楼主的测试软件再哪搞了^能否提供下!
[解决办法]不错。。学习中，LZ的考证精神
