第三章 查询处理

逻辑查询处理：(8) SELECT (9) DISTINCT <select_list>

(1) FROM <left_table>

(3) <join_type> JOIN <right_table>

(2) ON <join_condition>

(4) WHERE <where_condition>

(5) GROUP BY <group_by_list>

(6) WITH {CUBE|ROLLUP}

(7) HAVING <having_condition>

(10) ORDER BY <order_by_list>

(11) LIMIT <limit_number>

SELECT一共有3个过滤过程，WHERE,ON,HAVING, ON是最先执行的过滤过程。

WHERE过滤器中：

1.由于数据还没有分组，因此现在还不能在WHERE过滤器中使用where_condition=MIN(col)这类对攻击的过滤

2.由于还没有进行列的选取操作，因此在SELECT中使用列的别名也是不被允许的，如SELECT city AS c FROM t WHERE c='ShangHai'是不允许出现的。

在WHERE过滤器中进行的过滤和在ON过滤器中进行的过滤是有所不同的。对于OUTERJOIN中的过滤，在ON过滤器过滤完之后还会添加保留表中被ON条件过滤掉的记录，而WHERE条件中被过滤掉的记录则是永久的过滤。在INNER JOIN中两者是没有差别的，因为没有添加外部行的操作。

3. HAVING是对分组条件进行过滤的筛选器，子查询不能用作分组的聚合函数，如HAVING COUNT(SELECT ...)<2是不合法的。

4. SELECT：列的别名不能在SELECT中的其他别名表达式中使用，如：

　　mysql>SELECT order_id AS o, o+1 AS n FROM orders;

　　

5. DISTINCT: 如果在查询中指定了DISTINCT子句，则会创建一张内存临时表(如果内存中存放不下就放到磁盘上)。这张内存临时表的表结构和上一步产生的虚拟表一样，不同的是对进行DISTINCT操作的列增加了一个唯一索引，以此来去除重复数据。另外，对于使用了GROUP BY的查询，在使用DISTINCT是多余的，因为已经进行分组了，不会移除任何行。

6. 大多数DBA和开发人员都错误的认为在选取表中的数据时，记录会按照表中主键的大小顺序的取出，即结果像进行了ORDER BY一样。导致这个经典错误的原因主要是没有理解什么才是真正的关系数据库。数据库中常见的查询操作其实对应的是集合的某些运算：选择、投影、连接、并、交、差、除。最终的结果虽然是以一张二维表的方式呈现在用户面前，但是从数据库内部来看是一系列的集合操作。因此，对于表中的记录，用户需要以集合的思想来理解。没有ORDER BY子句的查询只代表从集合中查询数据，而集合是没有顺序概念的。因此要牢记，不用为表中的行假设任何特定的顺序。

7. LIMIT：从上一步骤的虚拟表中选出从指定位置开始的指定行数据。对应没有应用ORDER BY的LIMIT字句，结果同样可能是无序的，因此LIMIT子句通常和ORDER BY一起使用。

　　LIMIT n,m

表示从第n条记录开始选择m条记录。而大多数开发人员喜欢使用这类语句来解决web中经典的分页问题。对于小规模的数据，这并不会有太大的问题。但是对于大规模数据来说，LIMIT n,m效率是十分低的。因为每次都需要对数据进行选取。