不必深入浅出:不使用准备好的语句。

使用无意义的表别名:

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

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

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

我需要把我自己目前最喜欢的放在这里，只是为了使列表完整。我最喜欢的反模式是不测试您的查询。

这适用于以下情况:

您的查询涉及多个表。 您认为您有一个查询的最优设计，但不需要测试您的假设。 您接受第一个有效的查询，不知道它是否接近优化。

任何针对非典型或不充分数据进行的测试都不算数。如果它是一个存储过程，将测试语句放入注释中并保存它，并保存结果。否则，将其与结果一起放入代码中的注释中。

The Altered View - A view that is altered too often and without notice or reason. The change will either be noticed at the most inappropriate time or worse be wrong and never noticed. Maybe your application will break because someone thought of a better name for that column. As a rule views should extend the usefulness of base tables while maintaining a contract with consumers. Fix problems but don't add features or worse change behavior, for that create a new view. To mitigate do not share views with other projects and, use CTEs when platforms allow. If your shop has a DBA you probably can't change views but all your views will be outdated and or useless in that case. The !Paramed - Can a query have more than one purpose? Probably but the next person who reads it won't know until deep meditation. Even if you don't need them right now chances are you will, even if it's "just" to debug. Adding parameters lowers maintenance time and keep things DRY. If you have a where clause you should have parameters. The case for no CASE - SELECT CASE @problem WHEN 'Need to replace column A with this medium to large collection of strings hanging out in my code.' THEN 'Create a table for lookup and add to your from clause.' WHEN 'Scrubbing values in the result set based on some business rules.' THEN 'Fix the data in the database' WHEN 'Formating dates or numbers.' THEN 'Apply formating in the presentation layer.' WHEN 'Createing a cross tab' THEN 'Good, but in reporting you should probably be using cross tab, matrix or pivot templates' ELSE 'You probably found another case for no CASE but now I have to edit my code instead of enriching the data...' END

应用程序连接 不仅仅是一个SQL问题，而是在寻找问题的描述和发现这个问题时，我很惊讶它没有被列出。

正如我所听到的那样，应用程序连接是指从两个或多个表中取出一组行，然后用一对嵌套的for循环将它们连接到(Java)代码中。这给系统(应用程序和数据库)带来了负担，必须识别整个叉乘，检索它并将其发送给应用程序。假设应用程序可以像数据库一样快地过滤叉乘(不确定)，只是更快地削减结果集意味着更少的数据传输。