我想补充一点: 偏好“优雅”代码而不是高性能代码。在应用程序开发人员看来，对数据库最有效的代码通常是丑陋的。

Believing that nonsense about premature optimization. Databases must consider performance in the original design and in any subsequent development. Performance is 50% of database design (40% is data integrity and the last 10% is security) in my opinion. Databases which are not built from the bottom up to perform will perform badly once real users and real traffic are placed against the database. Premature optimization doesn't mean no optimization! It doesn't mean you should write code that will almost always perform badly because you find it easier (cursors for example which should never be allowed in a production database unless all else has failed). It means you don't need to look at squeezing out that last little bit of performance until you need to. A lot is known about what will perform better on databases, to ignore this in design and development is short-sighted at best.

当查询在您的开发机器上运行得如此之快时，一旦您向应用程序抛出一些流量，查询就会崩溃并阻塞，这要归咎于db引擎。

开发人员所犯的关键数据库设计和编程错误

Selfish database design and usage. Developers often treat the database as their personal persistent object store without considering the needs of other stakeholders in the data. This also applies to application architects. Poor database design and data integrity makes it hard for third parties working with the data and can substantially increase the system's life cycle costs. Reporting and MIS tends to be a poor cousin in application design and only done as an afterthought. Abusing denormalised data. Overdoing denormalised data and trying to maintain it within the application is a recipe for data integrity issues. Use denormalisation sparingly. Not wanting to add a join to a query is not an excuse for denormalising. Scared of writing SQL. SQL isn't rocket science and is actually quite good at doing its job. O/R mapping layers are quite good at doing the 95% of queries that are simple and fit well into that model. Sometimes SQL is the best way to do the job. Dogmatic 'No Stored Procedures' policies. Regardless of whether you believe stored procedures are evil, this sort of dogmatic attitude has no place on a software project. Not understanding database design. Normalisation is your friend and it's not rocket science. Joining and cardinality are fairly simple concepts - if you're involved in database application development there's really no excuse for not understanding them.

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

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

我想补充一点: 偏好“优雅”代码而不是高性能代码。在应用程序开发人员看来，对数据库最有效的代码通常是丑陋的。

Believing that nonsense about premature optimization. Databases must consider performance in the original design and in any subsequent development. Performance is 50% of database design (40% is data integrity and the last 10% is security) in my opinion. Databases which are not built from the bottom up to perform will perform badly once real users and real traffic are placed against the database. Premature optimization doesn't mean no optimization! It doesn't mean you should write code that will almost always perform badly because you find it easier (cursors for example which should never be allowed in a production database unless all else has failed). It means you don't need to look at squeezing out that last little bit of performance until you need to. A lot is known about what will perform better on databases, to ignore this in design and development is short-sighted at best.

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

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