在修复生产数据库内部的一些问题之前没有进行备份。 在存储过程中的存储对象(如表、视图)上使用DDL命令。 害怕使用存储的proc或害怕在更有效/更合适的地方使用ORM查询。 忽略数据库分析器的使用，它可以准确地告诉您ORM查询最终转换为什么，从而验证逻辑，甚至在不使用ORM时进行调试。

我讨厌开发人员使用嵌套的选择语句，甚至在查询的“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和内存使用。

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

a)在字符串中硬编码查询值 b)将数据库查询代码放在Windows窗体应用程序的“OnButtonPress”操作中

两者我都见过。

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

如果您正在使用复制(MySQL)，以下函数是不安全的，除非您正在使用基于行的复制。

USER(), CURRENT_USER() (or CURRENT_USER), UUID(), VERSION(), LOAD_FILE(), and RAND()

参见:http://dev.mysql.com/doc/refman/5.1/en/replication-features-functions.html