除了他们使用的语法和概念选项(例如连接、触发器和存储过程)之外，对于每个使用数据库的开发人员来说，有一件事是至关重要的:

了解您的引擎将如何执行您正在编写的查询。

我认为这很重要的原因仅仅是生产的稳定性。您应该知道您的代码是如何执行的，这样您就不会在等待一个长函数完成时停止线程中的所有执行，那么为什么您不想知道您的查询将如何影响数据库、程序甚至服务器呢?

This is actually something that has hit my R&D team more times than missing semicolons or the like. The presumtion is the query will execute quickly because it does on their development system with only a few thousand rows in the tables. Even if the production database is the same size, it is more than likely going to be used a lot more, and thus suffer from other constraints like multiple users accessing it at the same time, or something going wrong with another query elsewhere, thus delaying the result of this query.

即使是像连接如何影响查询性能这样简单的事情，在生产中也是非常宝贵的。许多数据库引擎的许多特性在概念上让事情变得更简单，但如果没有考虑清楚，可能会在性能上带来问题。

了解数据库引擎的执行过程，并为之制定计划。

对于一些项目，面向对象模型更好。

对于其他项目，关系模型更好。

归一化

我总是很沮丧地看到有人努力编写一个过度复杂的查询，而这个查询用标准化的设计可以完全简单明了(“显示每个地区的总销售额。”)。

如果您在一开始就理解了这一点，并相应地进行设计，您将在以后为自己省去许多痛苦。在规范化之后，很容易对性能进行反规范化;要规范化一个从一开始就不是这样设计的数据库并不容易。

至少，您应该知道3NF是什么以及如何实现它。对于大多数事务性数据库，这是使查询易于编写和保持良好性能之间的一个很好的平衡。

关于数据库，开发人员应该知道的第一件事是:数据库是用来干什么的?不是它们如何工作，也不是如何构建它们，甚至不是如何编写代码来检索或更新数据库中的数据。但是它们有什么用呢?

不幸的是，这个问题的答案是一个移动的目标。在数据库的鼎盛时期，20世纪70年代到90年代初，数据库是为了共享数据。如果你正在使用一个数据库，而你没有共享数据，那么你要么是在参与一个学术项目，要么就是在浪费资源，包括你自己。建立一个数据库和驯服一个DBMS是如此巨大的任务，就数据被多次利用而言，回报必须与投资相匹配。

Over the last 15 years, databases have come to be used for storing the persistent data associated with just one application. Building a database for MySQL, or Access, or SQL Server has become so routine that databases have become almost a routine part of an ordinary application. Sometimes, that initial limited mission gets pushed upward by mission creep, as the real value of the data becomes apparent. Unfortunately, databases that were designed with a single purpose in mind often fail dramatically when they begin to be pushed into a role that's enterprise wide and mission critical.

关于数据库，开发人员需要了解的第二件事是整个以数据为中心的视图。以数据为中心的世界观不同于以流程为中心的世界观，这是大多数开发人员所学过的最不同的观点。与这个差距相比，结构化编程和面向对象编程之间的差距相对较小。

开发人员需要学习的第三件事是数据建模，包括概念数据建模、逻辑数据建模和物理数据建模。

概念数据建模实际上是从以数据为中心的角度进行需求分析。

逻辑数据建模通常是将特定的数据模型应用于概念数据建模中发现的需求。关系模型的使用比任何其他特定模型都要多，开发人员肯定需要学习关系模型。为一个重要的需求设计一个强大且相关的关系模型并不是一项简单的任务。如果误解了关系模型，就无法构建良好的SQL表。

物理数据建模通常是特定于DBMS的，不需要了解太多细节，除非开发人员同时也是数据库构建者或DBA。开发人员需要了解的是，物理数据库设计可以在多大程度上与逻辑数据库设计分离，以及仅通过调整物理设计就可以在多大程度上生成高速数据库。

开发人员需要了解的下一件事是，虽然速度(性能)很重要，但其他衡量设计好坏的指标更重要，比如修改和扩展数据库范围的能力，或者编程的简单性。

最后，任何与数据库打交道的人都需要明白，数据的价值往往比捕获数据的系统更持久。

唷!

永远不要以错误的文本编码插入数据。

一旦您的数据库受到多种编码的污染，您所能做的最好的事情就是应用启发式和手工劳动的某种组合。

索引的工作原理

这可能不是最重要的，但肯定是最被低估的话题。

索引的问题在于SQL教程通常根本不会提到它们，而且所有的玩具示例都可以在没有索引的情况下工作。

即使更有经验的开发人员也可以编写相当好的(和复杂的)SQL，而不需要了解更多关于索引的知识，而只是“索引使查询更快”。

这是因为SQL数据库作为黑盒的工作做得非常好:

告诉我你需要什么(给我SQL)，我来处理。

这可以很好地检索正确的结果。SQL的作者不需要知道系统在幕后做什么——直到一切变得非常缓慢.....

这时索引就成了一个话题。但这通常很晚了，而且某些人(一些公司?)已经遇到了真正的问题。

这就是为什么我认为索引是在使用数据库时不能忘记的首要主题。不幸的是，它很容易忘记。

免责声明

这些论点是从我的免费电子书“使用索引，卢克”的序言中借来的。我花了很多时间来解释索引是如何工作的，以及如何正确地使用它们。