这之前已经说过了，但是:索引，索引，还是索引。我见过许多性能不佳的企业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”更容易使用。

1 -在where子句中的值上不必要地使用函数，导致该索引未被使用。

例子:

where to_char(someDate,'YYYYMMDD') between :fromDate and :toDate

而不是

where someDate >= to_date(:fromDate,'YYYYMMDD') and someDate < to_date(:toDate,'YYYYMMDD')+1

在较小的程度上:不向需要函数索引的值添加函数索引……

2 -没有添加检查约束以确保数据的有效性。查询优化器可以使用约束，它们确实有助于确保您可以信任您的不变量。没有理由不使用它们。

3 -纯粹出于懒惰或时间压力而向表中添加未规范化的列。事情通常不是这样设计的，而是演变成这样的。最终的结果是，当您在未来的演进中受到丢失的数据完整性的困扰时，将会有大量的工作试图清理混乱。

想想看，重新设计一个没有数据的表是非常便宜的。一个有数百万条记录的表，没有完整性……重新设计并不便宜。因此，在创建列或表时执行正确的设计是可以分摊的。

4 -不是关于数据库本身，但确实令人讨厌。不关心SQL的代码质量。SQL是用文本表示的事实并不意味着可以将逻辑隐藏在大量的字符串操作算法中。完全有可能用文本编写SQL，使您的程序员同事能够读懂。

忘记在表之间建立关系。我记得当我刚开始在我现在的雇主工作时，我不得不清理这些东西。

对于基于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.

许多开发人员倾向于对数据库执行多个查询(通常查询一个或两个表)，提取结果并在java/c/c++中执行简单的操作——所有这些都可以用一条SQL语句完成。

许多开发人员通常没有意识到，在开发环境中，数据库和应用程序服务器在他们的笔记本电脑上——但在生产环境中，数据库和应用程序服务器将在不同的机器上。因此，对于每个查询，在应用程序服务器和数据库服务器之间传递的数据都有额外的n/w开销。我惊奇地发现，为了向用户呈现一个页面，应用程序服务器对数据库服务器进行了大量的数据库调用!

不了解数据库并发模型以及它如何影响开发。事后添加索引和调整查询很容易。然而，应用程序的设计没有适当考虑热点，资源争用 和正确的操作(假设您刚刚阅读的内容仍然有效!)可能需要在数据库和应用层中进行重大更改，以便稍后纠正。