对于存储时间值，应该只使用UTC时区。不应使用当地时间。

FROM TableA, TableB WHERE语法用于连接而不是FROM TableA内部连接TableB上 假设查询将以某种方式返回，而不放入ORDER BY子句，因为这是在查询工具中测试时显示的方式。

我见过太多人死死抓着IN(…)，却完全忘记了EXISTS(存在)。有关一个好例子，请参见Symfony Propel ORM。

使用无意义的表别名:

from employee t1,
department t2,
job t3,
...

使得阅读一个大的SQL语句比它需要的要困难得多

反向观点:过度痴迷于正常化。

大多数SQL/ rbdb系统提供了许多非常有用的特性(事务、复制)，即使对于非标准化的数据也是如此。磁盘空间很便宜，有时操作/过滤/搜索获取的数据比编写1NF模式更简单(更容易的代码，更快的开发时间)，并处理其中的所有麻烦(复杂的连接，讨厌的子选择等)。

我发现过度标准化的系统通常是不成熟的优化，特别是在开发的早期阶段。

(再想想……http://writeonly.wordpress.com/2008/12/05/simple-object-db-using-json-and-python-sqlite/)

编写查询的开发人员没有很好地了解SQL应用程序(包括单个查询和多用户系统)的快慢。这包括对以下方面的无知:

physical I/O minimization strategies, given that most queries' bottleneck is I/O not CPU perf impact of different kinds of physical storage access (e.g. lots of sequential I/O will be faster than lots of small random I/O, although less so if your physical storage is an SSD!) how to hand-tune a query if the DBMS produces a poor query plan how to diagnose poor database performance, how to "debug" a slow query, and how to read a query plan (or EXPLAIN, depending on your DBMS of choice) locking strategies to optimize throughput and avoid deadlocks in multi-user applications importance of batching and other tricks to handle processing of data sets table and index design to best balance space and performance (e.g. covering indexes, keeping indexes small where possible, reducing data types to minimum size needed, etc.)