SQL牛人指点指点
一直很重视Sql语句编写，也认真学习了一些，不过由于是菜鸟面对高深的Sql差的还很多，问一些困惑的问题：

 1.子查询和join在什么情况下各自优势是什么，看Sql Server很多都是把子查询转换为left join语句，很多同事都说left join好，但没有说清楚好在哪里？ 有些子查询改成left join反而评估时占用cpu更高些，说什么哈希匹配？不懂，请大牛解惑。。。
详细说一些……或者给一些牛人博客链接（其实已经看了很多博客了……）!

 2.为什么有些企业规定不让用存储过程，难道仅仅怕维护吗？

 3.建表时，企业项目建表时哪些使用自增ID，哪些情况不使用自增。

 4.使用with as tab 这种临时保存的表好吗？

 5.有些表的逻辑复杂，像查询A表一些字段需要从其他表统计出来，那如果在A表中创建这些字段，更新的时候，多修改一些这个字段，省得以后查询了，，那种方式好，实时的从其他表中查询填充A表，还是每次相应的修改都更新A表的对应字段。。

大牛给小弟解惑，非常感谢！

------解决方案--------------------
1.使用JOIN的话 可以在连接字段加索引 从而加快查询速度。
2.把全部业务逻辑写在存储过程中的话，维护很不方便。而且很多时候在程序端解决业务逻辑的话，比写存储过程简单，效率也不会太低。
3.根据需求做出选择，没有什么定性的东西。
4.这个叫做公用表达式，而不是保存临时表。
5.适当的冗余是可以存在的。
------解决方案--------------------
使用JOIN的话 可以在连接字段加索引 从而加快查询速度。
2.把全部业务逻辑写在存储过程中的话，维护很不方便。而且很多时候在程序端解决业务逻辑的话，比写存储过程简单，效率也不会太低。
------解决方案--------------------
根据的你需要来做，把概念先搞清楚。
------解决方案--------------------
1、这个很多时候优化器会优化成以一样的结果。两者一样
2、这个看上面头的想法了，有的喜欢这么搞 有的喜欢那么搞
但是有一点，存储过程只是去写数据逻辑的，不能把业务逻辑也用存储过程写
3、一般都是自增主键，自增不是每个表必备，但是主键，每个表都要有（当然也有特殊情况）
4、cte 这个东西很多时候只是让代码看起来简洁了
5、适当的冗余挺好的，减少了查询难度，提高了查询速度

------解决方案--------------------

SQL code

1、如上小F姐说的，子查询最大的问题查询时的逻辑处理与物理处理的不一致性上。
即随着数据情况的变化，，会产生不止一种物理处理方法来处理相关的子查询。
这在程序编制过程中，会产生一些查询错误。  比如：in 以及null值的问题。

2、通常这个是一个选择的问题。如果企业的数据库管理方面的能力强些，那么做在
数据库端的就会多些。反之，就会在前端程序侧更多的处理。就现在很多的强制做法
来看，前端的程序处理能力要强不少。

3、这个问题，就看需求了，需要就用，不需要就不用的。

4、公用表表达式（CTE）

5、实际使用中，不可能完全按照范式来处理。冗余的使用情况，并不少见。跟F姐说的一样
适当即可。

------解决方案--------------------
探讨

我上面第一个说反了，是有的left join改成子查询效率反而更高了！怎么回事？执行计划说什么哈希匹配……
还有就是索引的问题，在某一个时间字段上创建所有效率果然很高了，但是但和另一个没有索引的字段一起做为条件时就慢了不少，比俩个字段都不加索引慢了，这又是为什么！？
@大牛，索引方面给说说，给个好的链接也ok！