不对数据库模式使用版本控制 直接针对活动数据库工作 没有阅读和理解更高级的数据库概念(索引、聚集索引、约束、物化视图等) 没有测试可伸缩性……只有3或4行的测试数据永远不会给您真实的实时性能的真实画面

因为“它太神奇了”或“不在我的数据库中”这样的原因，而放弃像Hibernate这样的ORM。 过度依赖像Hibernate这样的ORM，并试图将它硬塞到不合适的地方。

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，使您的程序员同事能够读懂。

这里有一个视频链接，名为“经典数据库开发错误和克服它们的五种方法”，作者是Scott Walz

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

使用一些疯狂的构造和应用逻辑，而不是简单的COALESCE。