1、是一样的。后一种写法是sql92标准规定的。适用于任何支持这一标准的RDBMS。
2、你要为每个表写明：a.id=1 and b.id=1 and ..这样才能在各个表中先进行filter操作。否则只能在连接操作时filter。
3、是的。要尽量缩小每个表的记录范围。
4、外连接和内连接的逻辑操作是不同的，即其关系代数含义是不一样的！虽然物理操作可能是一致的（效率可能也一致）但是他们是没有可比性的。
5、差不多。但是前提是你的RDBMS的基于成本的优化器要足够聪明！如果在sql2005或oracle10g可能会一致，但是在低版本的产品中有可能不一致。需要实际观察。
6、这和你的业务要求有关系。尽量减少大记录集的返回。
7、在用户层面你可以这么认为（也只能这么认为）。
2、你要为每个表写明：a.id=1 and b.id=1 and ..这样才能在各个表中先进行filter操作。否则只能在连接操作时filter。
3、是的。要尽量缩小每个表的记录范围。
4、外连接和内连接的逻辑操作是不同的，即其关系代数含义是不一样的！虽然物理操作可能是一致的（效率可能也一致）但是他们是没有可比性的。
5、差不多。但是前提是你的RDBMS的基于成本的优化器要足够聪明！如果在sql2005或oracle10g可能会一致，但是在低版本的产品中有可能不一致。需要实际观察。
6、这和你的业务要求有关系。尽量减少大记录集的返回。
7、在用户层面你可以这么认为（也只能这么认为）。
2. left join 的情况, sql不能充分优化查询, 当A表有100万数据, D表有1000条记录时(A/D表是多对1关系), 由于left join始终以A表为基础, 因此无法先做A与D的计算, 缩小数据处理范围, 而 inner join 可以做到(即不受join语句中表的顺序的影响)
3. 处理条件和join条件的顺序问题, 这个没有绝对指标, sql会根据表结构/数据/及查询语句的写法自动优化, 这是不可控的
4. join的处理方式的问题, 一般有三种(sql也是根据你的表结构/数据/及查询语句的写法自动选择最优方案):
a. 某个表为基础, 逐条记录扫描并与另一表匹配
b. 两表同时扫描匹配
c. 通过哈希值匹配
具体的楼主需要查查书去找概念了
5. explain plan 相同, 效率一般是一致的, explain plan 不能反映出执行时的所有细节, 所以explain plan 一致, 不能代表具体的执行细节完全一致, 所以效率也不一定完全一致.