最近一个朋友和我探讨关于Where 1=1 and这种形式的语句会不会影响性能。最后结论是不影响。
虽然结论正确，但对问题的认识却远远没有解决问题的根本。实际上在T-SQL语句的书写过程中经常犯得错误就是得出一个很窄的结论，然后教条式的奉若圣经，对于T-SQL领域来说，在网上经常可以看到所谓的优化守则，随便在网上搜了一些摘录如下：
不要有超过5个以上的表连接（JOIN）
考虑使用临时表或表变量存放中间结果
少用子查询
视图嵌套不要过深,一般视图嵌套不要超过2个为宜。
对出现在where子句中的字段加索引
避免在索引列上使用函数或计算，在where子句中，如果索引是函数的一部分，优化器将不再使用索引而使用全表扫描
在insert和update维表时都加上一个条件来过滤维表中已经存在的记录
如果使用了IN或者OR等时发现查询没有走索引，使用显式申明指定索引
EXISTS要远比IN的效率高。
……….
我们这里假设查询分析器在代数树优化阶段没有把where 1=1这种情况直接过滤掉。
比如语句select * from table where a=1 and b=2 这个语句，SQL Server估计的行数会是：
a列的选择率*b列的选择率*表中采样的总行数
因此，当Where 1=1 and a=1时，结果就变为
1*a列的选择率 *表中采样的总行数=a列的选择率 *表中采样的总行数
因此无论是否有1=1 and，查询分析器都会估计相同的行数，从而拥有同样的执行计划，因此不影响性能。
当我们明白了查询分析器对A and B这种写法是如何估计行数之后，那么我们就可以推算出什么情况A and B可能引起执行计划不准确。从公式来看，SQL Server认为A列和B列是无关联的，如果A和B关联很大，那么估计的行数一定会非常不准。
这里我们举例，假如表中有100万行数据，where a=1的数据有1万条，where b=1的数据有1万条，则A和B的选择性都是1/100=0.01，在Where中A And B联合的估计行数则变为0.01*0.01=0.0001*100万=100行，假设where a=1 和b=1所筛选的数据为同样的1万行数据，则估计行数为100而实际行数为1万，则可能引起执行计划的不准确，从而引起性能问题。当然，这种情况的确是少数，但发生后往往对性能有一定影响，因此SQL Server 2014新的行数估计采用了指数退让算法，在这种情况下就会估计为1000行，从而引起性能问题的可能性会变小，2014指数退让算法不是本文的重点，因此也不多讲了。
随时随地看视频
