过度使用临时表和游标。

编写查询的开发人员没有很好地了解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.)

在他们职业生涯的前6个月学习SQL，在接下来的10年里从不学习其他任何东西。特别是没有学习或有效地使用窗口/分析SQL特性。特别是over()和partition by的使用。

窗口函数，比如聚合 函数时，对对象进行聚合 定义的行集(组)，但是 而不是返回一个值 组，窗口函数可以返回 每个组有多个值。

请参阅O'Reilly SQL Cookbook附录A，以获得窗口函数的良好概述。

1)我不知道这是否是一个“官方的”反模式，但我不喜欢并试图避免在数据库列中使用字符串文字作为魔法值。

MediaWiki表'image'中的一个例子:

img_media_type ENUM("UNKNOWN", "BITMAP", "DRAWING", "AUDIO", "VIDEO", 
    "MULTIMEDIA", "OFFICE", "TEXT", "EXECUTABLE", "ARCHIVE") default NULL,
img_major_mime ENUM("unknown", "application", "audio", "image", "text", 
    "video", "message", "model", "multipart") NOT NULL default "unknown",

(我只是注意到不同的大小写，另一个要避免的事情)

我设计了这样的情况，int查找表ImageMediaType和ImageMajorMime与int主键。

2)日期/字符串转换，依赖于特定的NLS设置

CONVERT(NVARCHAR, GETDATE())

没有格式标识符

把东西放在临时表中，特别是那些从SQL Server切换到Oracle的人有过度使用临时表的习惯。只需使用嵌套的选择语句。

有一张桌子

code_1
value_1
code_2
value_2
...
code_10
value_10

而不是有3个表

Code, value和code_value

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

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