第一个问题?他们只在玩具数据库上测试。因此，他们不知道当数据库变大时，他们的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

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

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

使用Access而不是“真正的”数据库。有很多很棒的小型甚至免费的数据库，比如SQL Express、MySQL和SQLite，它们可以更好地工作和扩展。应用程序通常需要以意想不到的方式进行扩展。

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

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.