最大的错误是在代码中使用循环更新或插入数据，而基于集合的简单解决方案可以更快、更简单地完成这一任务。

有一件事我想补充，学习使用分析函数，如分区BY, RANK, DENSE_RANK (Oracle)。它们对于复杂的查询是绝对必要的。

其他建议是，如果可能的话，在您的开发团队中有一个专门的数据库开发人员，他应该是SQL、数据库建模、调优等方面的专家(但不是DBA)。这种技能是一笔巨大的财富。

认为他们是dba和数据建模师/设计人员，而他们在这些领域没有任何正式的灌输。 认为他们的项目不需要DBA，因为这些东西都很简单/琐碎。 未能正确区分应该在数据库中完成的工作和应该在应用程序中完成的工作。 未验证备份，或未备份。 在他们的代码中嵌入原始SQL。

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

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

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

我讨厌开发人员使用嵌套的选择语句，甚至在查询的“select”部分中返回选择语句的结果的函数。

我很惊讶我在其他地方没有看到这个，也许我忽略了它，尽管@adam也有类似的问题。

例子:

SELECT
    (SELECT TOP 1 SomeValue FROM SomeTable WHERE SomeDate = c.Date ORDER BY SomeValue desc) As FirstVal
    ,(SELECT OtherValue FROM SomeOtherTable WHERE SomeOtherCriteria = c.Criteria) As SecondVal
FROM
    MyTable c

在这个场景中，如果MyTable返回10000行，结果就好像查询只运行了20001个查询，因为它必须运行初始查询，并对每一行结果查询一次其他表。

开发人员可以在只返回几行数据且子表通常只有少量数据的开发环境中使用这种查询，但在生产环境中，随着向表中添加更多数据，这种查询的成本可能会呈指数级增长。

一个更好的(不一定完美的)例子是这样的:

SELECT
     s.SomeValue As FirstVal
    ,o.OtherValue As SecondVal
FROM
    MyTable c
    LEFT JOIN (
        SELECT SomeDate, MAX(SomeValue) as SomeValue
        FROM SomeTable 
        GROUP BY SomeDate
     ) s ON c.Date = s.SomeDate
    LEFT JOIN SomeOtherTable o ON c.Criteria = o.SomeOtherCriteria

这允许数据库优化器将数据混合在一起，而不是从主表中重新查询每条记录，我通常发现，当我必须修复产生这个问题的代码时，我通常会将查询速度提高100%或更多，同时减少CPU和内存使用。