neil-zhao

摘要： 本文主要介绍写SQL的另外两个误区：1、存储过程中使用局部变量而不使用参数变量（就是存储过程输入参数）做where条件2、查询条件中类型不匹配这两种错误都是非常非常容易犯且非常发指的错误，特别是2，太多次见过了。一、关于存储过程使用局部变量，我们举例说明。有这么一张表存储过程：create proc test( @id int)as select * from charge where charg... 阅读全文

摘要： 我们先看NestedLoop和MergeJoin的算法（以下为引用，见RicCC的《通往性能优化的天堂-地狱 JOIN方法说明》):==================================NestedLoop:foreach rowA in tableA where tableA.col2=? { search rowsB from tableB where tableB.col1=r... 阅读全文

摘要： 先站在应用程序的角度说说它们的不同。1、直接拼SQL就像大家了解的那样，直接拼SQL带来了SQL注入攻击，带来了拼时些许的性能损失，但是拼不用添加SqlParameter，会少写很多代码——很多人喜欢直接拼，也许就因为这点。这种做法会把你拼好的SQL原样直接发送到DB服务器去执行。（注意类似”exec yourproc ‘param1’,... 阅读全文

摘要： 上回我们说到评估一条语句执行效率主要看逻辑IO（啥是逻辑IO，啥是物理IO见联机文档），这次我们继续。我们先说说，返回多行结果时，为什么SQLServer有时会选择index seek，有时会选择index scan。以nonclustered index为例说明。像所有的索引B树一样，非聚集索引树也包括完全由索引数据组成的根节点和中间级节点；但是和聚集索引树不同的是，聚集索引树叶节点包含的是基础... 阅读全文

摘要： 大型系统的生产环境，一般情况下，我们评价一条查询是否有效率，更多的是关注逻辑IO(至于为什么，回头补一篇)。我们常说，“要建彪悍的索引”、“要写高效的SQL”，其实最终目的就是在相同结果集情况下，尽可能减少逻辑IO。1.1 where条件的列上都得有统计信息。没统计信息SQLServer就无法估算不同查询计划开销优劣，而只能采用最稳妥的Scan（不管... 阅读全文

摘要： 先说说这些误区。所谓“误区”，有一些是新手很容易犯的错误或者很容易忽略的问题，另外一些，则是像“耗子吃了盐会变成蝙蝠”一样，让我们从小就认为是正确的事情。如下：1、表上不管用得着用不着，都加个聚集索引。我们知道，表以两种方式组织物理存储：有聚集索引的“聚集表”；没有聚集索引的“堆”。在聚集表中，数据行按... 阅读全文