一般在写SQL时需要注意哪些问题，可以提高查询的效率？

学SQL语句性能的时候要注意非常重要一点：
不要用程序开发的思维思考数据库！！
在数据库中，SQL语句是一个抽象的概念，而不代表具体的实现。我举一个简单的例子，比如说A表和B表做连接，具体的Loop Join实现逻辑的伪代码为：

for each row in t1 matching range {  
for each row in t2 matching reference key {   
for each row in t3 {      
if row satisfies join conditions,      
send to client   
 } 
 }
}

而写SQL语句的时候，仅仅需要写select * from a inner join b on a.clo1=b.col2，该SQL语句仅仅写了你希望获得的结果，而没有写任何实现逻辑，因此SQL是无关实现的、抽象的。
那么具体如何执行在关系数据库中都有一个所谓的“优化器”实现，现代关系数据库的优化器是基于成本选择具体执行步骤（执行计划）的。因此妨碍优化器选择最优执行计划的SQL就不是好SQL。
首先提一下楼主举出文章的几点观点，我一个个纠正：
1. 选择最有效率的表名顺序。
这肯定是不对的，SQL优化器不会关心写表时，哪个表在前，哪个表在后，再次强调，SQL是抽象的、无关实现的。该语句在逻辑优化阶段优化器会自动选择最优的计划。
2. WHERE子句中的连接顺序
同上。
3. SELECT子句中避免使用 ‘ * ‘
这一句话是正确的，但文章中提到：
“实际上,在解析的过程中, 会将’’ 依次转换成所有的列名, 这个工作是通过查询数据字典完成的, 这意味着将耗费更多的时间.”
这种理解是错误的，解析号的成本几乎可以忽略不计。而更多的成本在于如下：
读取多余的列可能导致索引的书签查找，当读取条目多时会无法使用特定索引。
如果select 作用于表连接，可能造成更大的成本开销。
4. 计算记录条数
文章提到：count() 比count(1)稍快 这属于以讹传讹了，count()函数是聚合函数，指的是计算count()中所有非null的条目，count(1)和count(*)都是常量，意味着计算所有非空列。想象一下select 1 from 表，表中有10行的话就会返回10个1。count（）同理，默认一般RDBMS会选择最窄的非Null列上的索引去统计具体条数。
5. 使用表的别名(Alias)
文中提到使用别名减少解析时间，我只能评论太有想象力了。
6. 用Where子句替换HAVING子句
这点的说法不合适，where和having是完全不同的子句，having的价值是使用聚合函数作为筛选条件中的一部分。没有谁替代谁一说。

那什么样的SQL语句是不好的语句呢：
那就是妨碍优化器更好的实现执行逻辑的SQL语句，这类语句包括：
1.where条件里出现各种花样百出的代码，比如函数、运算等。
2.语句过大，大量的表join会导致中间结果集不准确，从而限制优化器选择较好的执行计划。
等等.........

所以尝试尽量think like query optimizer,而不是think like programmer

对于索引的处理啦，语句内关联的使用啦。等等的