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

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

没有做正确的标准化。您希望确保数据没有重复，并且根据需要将数据分割为不同的数据。您还需要确保不要过于遵循规范化，否则会损害性能。

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

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

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