一直很重视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表的对应字段。。大牛给小弟解惑，非常感谢！
详细说一些……或者给一些牛人博客链接（其实已经看了很多博客了……）! 2.为什么有些企业规定不让用存储过程，难道仅仅怕维护吗？ 3.建表时，企业项目建表时哪些使用自增ID，哪些情况不使用自增。 4.使用with as tab 这种临时保存的表好吗？ 5.有些表的逻辑复杂，像查询A表一些字段需要从其他表统计出来，那如果在A表中创建这些字段，更新的时候，多修改一些这个字段，省得以后查询了，，那种方式好，实时的从其他表中查询填充A表，还是每次相应的修改都更新A表的对应字段。。大牛给小弟解惑，非常感谢！
2.把全部业务逻辑写在存储过程中的话，维护很不方便。而且很多时候在程序端解决业务逻辑的话，比写存储过程简单，效率也不会太低。
3.根据需求做出选择，没有什么定性的东西。
4.这个叫做公用表达式，而不是保存临时表。
5.适当的冗余是可以存在的。
2.把全部业务逻辑写在存储过程中的话，维护很不方便。而且很多时候在程序端解决业务逻辑的话，比写存储过程简单，效率也不会太低。
2、这个看上面头的想法了，有的喜欢这么搞 有的喜欢那么搞
但是有一点，存储过程只是去写数据逻辑的，不能把业务逻辑也用存储过程写
3、一般都是自增主键，自增不是每个表必备，但是主键，每个表都要有（当然也有特殊情况）
4、cte 这个东西很多时候只是让代码看起来简洁了
5、适当的冗余挺好的，减少了查询难度，提高了查询速度
即随着数据情况的变化，，会产生不止一种物理处理方法来处理相关的子查询。
这在程序编制过程中，会产生一些查询错误。 比如：in 以及null值的问题。2、通常这个是一个选择的问题。如果企业的数据库管理方面的能力强些，那么做在
数据库端的就会多些。反之，就会在前端程序侧更多的处理。就现在很多的强制做法
来看，前端的程序处理能力要强不少。3、这个问题，就看需求了，需要就用，不需要就不用的。4、公用表表达式（CTE）5、实际使用中，不可能完全按照范式来处理。冗余的使用情况，并不少见。跟F姐说的一样
适当即可。
还有就是索引的问题，在某一个时间字段上创建所有效率果然很高了，但是但和另一个没有索引的字段一起做为条件时就慢了不少，比俩个字段都不加索引慢了，这又是为什么！？
@大牛，索引方面给说说，给个好的链接也ok！
索引方面的链接 http://topic.csdn.net/u/20090401/09/AD67637B-63E0-4E75-8FFD-6B5B930B6044.html