3、把JOIN当做了SELECT的子句
　　对于性能或SQL语句的正确性来说，这不算错。但是不管如何，SQL开发者应该意识到JOIN子句不是SELECT语句的一部分。SQL standard 1992 定义了表引用：
6.3 <table reference>
<table reference> ::=
<table name> [ [ AS ] <correlation name>
[ <left paren> <derived column list> <right paren> ] ]
| <derived table> [ AS ] <correlation name>
[ <left paren> <derived column list> <right paren> ]
| <joined table>
7.4 <from clause>
<from clause> ::=
FROM <table reference> [ { <comma> <table reference> }... ]
7.5 <joined table>
<joined table> ::=
<cross join>
| <qualified join>
| <left paren> <joined table> <right paren>
<cross join> ::=
<table reference> CROSS JOIN <table reference>
<qualified join> ::=
<table reference> [ NATURAL ] [ <join type> ] JOIN
<table reference> [ <join specification> ]
　　关联数据库是以表为中心的。许多的操作的某方面都是执行在物理表、连接表或派生表上的。为了有效的写出SQL语句，理解SELECT … FROM子句是以“，”分割表引用是非常重要的。
　　基于表引用（table references）的复杂性，一些数据库也接受其它类型的复杂的表引用（table references），像INSERT、UPDATE、DELETE、MERGE。看看Oracle实例手册，里面解释了如何创建可更新的视图。
　　解决方案：
　　一定要考虑到，一般说来，FROM子句也是一个表引用（table references）。如果你写了JOIN子句，要考虑这个JOIN子句是这个复杂的表引用的一部分：
　　SELECT c.first_name， c.last_name， o.amount
　　FROMcustomer_view c
　　JOIN order_view o
　　ON c.cust_id = o.cust_id
　　4、使用ANSI 92标准之前连接语法
　　我 们已经说清了表引用是怎么工作的（看上一节），因此我们应该达成共识，不论花费什么代价，都应该避免使用ANSI 92标准之前的语法。执行计划而言，使用JOIN…ON子句或者WHERE子句来作连接谓语没有什么不同。但从可读性和可维护性的角度看，在过滤条 件判断和连接判断中用WHERE子句会陷入不可自拔的泥沼，看看这个简单的例子：
　　SELECT c.first_name， c.last_name， o.amount
　　FROM  customer_view c，
　　order_view o
　　WHERE  o.amount > 100
　　AND    c.cust_id = o.cust_id
　　AND    c.language = 'en'
　　你能找到join谓词么？如果我们加入数十张表呢？当你使用外连接专有语法的时候会变得更糟，像Oracle的（+）语法里讲的一样。
　　解决方案：
　　一定要用ANSI 92标准的JOIN语句。不要把JOIN谓词放到WHERE子句中。用ANSI 92标准之前的JOIN语法没有半点好处。
　　5、使用LIKE判定时忘了ESCAPE
　　SQL standard 1992 指出like判定应该如下：
　　8.5 <like predicate>
　　<like predicate> ::=
　　<match value> [ NOT ] LIKE <pattern>
　　[ ESCAPE <escape character> ]
　　当允许用户对你的SQL查询进行参数输入时，应该使用ESCAPE关键字。尽管数据中含有百分号（%）的情况很罕见，但下划线（_）还是很常见的：
　　SELECT *
　　FROM  t
　　WHERE  t.x LIKE 'some!_prefix%' ESCAPE '!'
　　解决方案：
　　使用LIKE判定时，也要使用合适的ESCAPE