过度使用和/或依赖存储过程。

一些应用程序开发人员将存储过程视为中间层/前端代码的直接扩展。这似乎是微软堆栈开发人员的一个共同特征(我是其中之一，但我已经不再这样做了)，并产生许多执行复杂业务逻辑和工作流处理的存储过程。这在其他地方做得更好。

存储过程在某些实际技术因素(例如性能和安全性)需要使用时非常有用。例如，保持大型数据集的聚合/过滤“接近数据”。

我最近不得不帮助维护和增强一个大型Delphi桌面应用程序，其中70%的业务逻辑和规则是在1400个SQL Server存储过程中实现的(其余在UI事件处理程序中)。这是一场噩梦，主要是由于难以将有效的单元测试引入TSQL，缺乏封装和糟糕的工具(调试器，编辑器)。

在过去与Java团队一起工作时，我很快发现在那个环境中，情况往往完全相反。一位Java架构师曾经告诉我:“数据库是用于数据的，而不是用于代码的。”

现在，我认为完全不考虑存储过程是错误的，但在它们提供有用好处的情况下，应该谨慎使用(不是默认情况)(参见其他答案)。

对于基于sql的数据库:

Not taking advantage of CLUSTERED INDEXES or choosing the wrong column(s) to CLUSTER. Not using a SERIAL (autonumber) datatype as a PRIMARY KEY to join to a FOREIGN KEY (INT) in a parent/child table relationship. Not UPDATING STATISTICS on a table when many records have been INSERTED or DELETED. Not reorganizing (i.e. unloading, droping, re-creating, loading and re-indexing) tables when many rows have been inserted or deleted (some engines physically keep deleted rows in a table with a delete flag.) Not taking advantage of FRAGMENT ON EXPRESSION (if supported) on large tables which have high transaction rates. Choosing the wrong datatype for a column! Not choosing a proper column name. Not adding new columns at the end of the table. Not creating proper indexes to support frequently used queries. creating indexes on columns with few possible values and creating unnecessary indexes. ...more to be added.

不使用参数化查询。它们在停止SQL注入时非常方便。

这是一个不消毒输入数据的具体例子，在另一个回答中提到过。

使用ORM进行批量更新 选择多于需要的数据。同样，这通常在使用ORM时完成 在循环中触发sql。 没有良好的测试数据，只在实时数据上注意到性能下降。

不了解DBMS的工作原理。

如果不了解离合器的工作原理，你就不能正确地驾驶变速杆。如果不了解实际上只是在硬盘上写入文件，就无法理解如何使用数据库。

具体地说:

Do you know what a Clustered Index is? Did you think about it when you designed your schema? Do you know how to use indexes properly? How to reuse an index? Do you know what a Covering Index is? So great, you have indexes. How big is 1 row in your index? How big will the index be when you have a lot of data? Will that fit easily into memory? If it won't it's useless as an index. Have you ever used EXPLAIN in MySQL? Great. Now be honest with yourself: Did you understand even half of what you saw? No, you probably didn't. Fix that. Do you understand the Query Cache? Do you know what makes a query un-cachable? Are you using MyISAM? If you NEED full text search, MyISAM's is crap anyway. Use Sphinx. Then switch to Inno.

这之前已经说过了，但是:索引，索引，还是索引。我见过许多性能不佳的企业web应用程序，它们通过简单地进行一些分析(查看哪些表被频繁访问)，然后在这些表上添加索引来解决问题。这甚至不需要太多的SQL编写知识，而且回报是巨大的。

Avoid data duplication like the plague. Some people advocate that a little duplication won't hurt, and will improve performance. Hey, I'm not saying that you have to torture your schema into Third Normal Form, until it's so abstract that not even the DBA's know what's going on. Just understand that whenever you duplicate a set of names, or zipcodes, or shipping codes, the copies WILL fall out of synch with each other eventually. It WILL happen. And then you'll be kicking yourself as you run the weekly maintenance script.

最后:使用清晰、一致、直观的命名约定。与一段编写良好的代码应该是可读的一样，一个好的SQL模式或查询应该是可读的，并且实际上告诉您它在做什么，甚至没有注释。六个月后，当你不得不对桌子进行维护时，你会感谢自己的。“选择account_number, billing_date FROM national_accounts”比“选择ACCNTNBR, BILLDAT FROM NTNLACCTS”更容易使用。