临时表滥用。

特别是这类事情:

SELECT personid, firstname, lastname, age
INTO #tmpPeople
FROM People
WHERE lastname like 's%'

DELETE FROM #tmpPeople
WHERE firstname = 'John'

DELETE FROM #tmpPeople
WHERE firstname = 'Jon'

DELETE FROM #tmpPeople
WHERE age > 35

UPDATE People
SET firstname = 'Fred'
WHERE personid IN (SELECT personid from #tmpPeople)

不要从查询中构建临时表，只是为了删除不需要的行。

是的，我在生产db中看到过这种形式的代码页。

有一张桌子

code_1
value_1
code_2
value_2
...
code_10
value_10

而不是有3个表

Code, value和code_value

你永远不知道什么时候你可能需要10对以上的代码，价值。

如果只需要一对，就不会浪费磁盘空间。

我最喜欢的SQL反模式:

对非唯一列进行JOIN，并使用SELECT DISTINCT修剪结果。

创建连接多个表的视图，只是为了从一个表中选择少数列。

 CREATE VIEW my_view AS 
     SELECT * FROM table1
     JOIN table2 ON (...)
     JOIN table3 ON (...);

 SELECT col1, col2 FROM my_view WHERE col3 = 123;

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

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

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

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

使用SQL作为美化的ISAM(索引顺序访问方法)包。特别是嵌套游标，而不是将SQL语句组合成一个更大的语句。这也算“滥用优化器”，因为实际上优化器能做的不多。这可以与非准备语句结合使用，以获得最大的效率:

DECLARE c1 CURSOR FOR SELECT Col1, Col2, Col3 FROM Table1

FOREACH c1 INTO a.col1, a.col2, a.col3
    DECLARE c2 CURSOR FOR
        SELECT Item1, Item2, Item3
            FROM Table2
            WHERE Table2.Item1 = a.col2
    FOREACH c2 INTO b.item1, b.item2, b.item3
        ...process data from records a and b...
    END FOREACH
END FOREACH

正确的解决方案(几乎总是)是将两个SELECT语句合并为一个:

DECLARE c1 CURSOR FOR
    SELECT Col1, Col2, Col3, Item1, Item2, Item3
        FROM Table1, Table2
        WHERE Table2.Item1 = Table1.Col2
        -- ORDER BY Table1.Col1, Table2.Item1

FOREACH c1 INTO a.col1, a.col2, a.col3, b.item1, b.item2, b.item3
    ...process data from records a and b...
END FOREACH

双循环版本的唯一优点是，您可以很容易地发现表1中值之间的中断，因为内部循环结束了。这可能是控制中断报告中的一个因素。

此外，应用程序中的排序通常是不允许的。

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