mysql数据库查询要注意_一般在写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子句中避免使用 ‘ * ‘

这一句话是正确的，但文章中提到：

“实际上,在解析的过程中, 会将’*’ 依次转换成所有的列名, 这个工作是通过查询数据字典完成的, 这意味着将耗费更多的时间.”

这种理解是错误的，解析*号的成本几乎可以忽略不计。而更多的成本在于如下：

1.读取多余的列可能导致索引的书签查找，当读取条目多时会无法使用特定索引。

2.如果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