- 博客(6)
- 资源 (7)
- 收藏
- 关注
转载 写有效率的SQL查询(V)
先站在应用程序的角度说说它们的不同。1、 直接拼SQL就像大家了解的那样,直接拼SQL带来了SQL注入攻击,带来了拼时些许的性能损失,但是拼不用添加SqlParameter,会少写很多代码——很多人喜欢直接拼,也许就因为这点。这种做法会把你拼好的SQL原样直接发送到DB服务器去执行。(注意类似”exec yourproc ‘param1’, 12”的语句不在此范畴,这是调用存储过
2008-07-21 21:58:00 1293
转载 写有效率的SQL查询(VI)
我们先看NestedLoop和MergeJoin的算法(以下为引用,见RicCC的《通往性能优化的天堂-地狱 JOIN方法说明》):==================================NestedLoop: foreach rowA in tableA where tableA.col2=? { search rowsB from tableB where
2008-07-21 21:58:00 1285
转载 写有效率的SQL查询(IV)
本文主要介绍写SQL的另外两个误区:1、 存储过程中使用局部变量而不使用参数变量(就是存储过程输入参数)做where条件2、 查询条件中类型不匹配这两种错误都是非常非常容易犯且非常发指的错误,特别是2,太多次见过了。 一、关于存储过程使用局部变量,我们举例说明。有这么一张表存储过程:create proc test( @id int)as
2008-07-21 21:57:00 1084
转载 写有效率的SQL查询(III)
先说说这些误区。所谓“误区”,有一些是新手很容易犯的错误或者很容易忽略的问题,另外一些,则是像“耗子吃了盐会变成蝙蝠”一样,让我们从小就认为是正确的事情。如下:1、 表上不管用得着用不着,都加个聚集索引。我们知道,表以两种方式组织物理存储:有聚集索引的“聚集表”;没有聚集索引的“堆”。在聚集表中,数据行按照聚集索引的顺序存储(这也是为啥一张表最多只能有一个聚集索引的原因);堆
2008-07-21 21:56:00 1108 1
转载 写有效率的SQL查询(II)
上回我们说到评估一条语句执行效率主要看逻辑IO(啥是逻辑IO,啥是物理IO见联机文档),这次我们继续。我们先说说,返回多行结果时,为什么SQLServer有时会选择index seek,有时会选择index scan。以nonclustered index为例说明。像所有的索引B树一样,非聚集索引树也包括完全由索引数据组成的根节点和中间级节点;但是和聚集索引树不同的是,聚集索引
2008-07-21 21:55:00 1163
转载 写有效率的SQL查询(I)
大型系统的生产环境,一般情况下,我们评价一条查询是否有效率,更多的是关注逻辑IO(至于为什么,回头补一篇)。我们常说,“要建彪悍的索引”、“要写高效的SQL”,其实最终目的就是在相同结果集情况下,尽可能减少逻辑IO。1.1 where条件的列上都得有统计信息。没统计信息SQLServer就无法估算不同查询计划开销优劣,而只能采用最稳妥的Scan(不管是table sca
2008-07-21 21:52:00 1302
SQL 2005 + CLR 压缩/解压 文件夹
2009-07-13
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人