database-design - 是否有创建适当数据库索引的策略？

Question

有人问了这个问题:“INT, BIGINT or UUID/GUID in Oracle, DB2, Derby and HSQLDB?”，我开始思考我设计的所有数据库模式和我读过的书，但没有一个引用提供任何真实 < em>明确关于创建索引的建议。

例如；如果你有一个像

这样的复合索引

date() ++ foo() ++ bar()

虽然此索引非常适合搜索和排序日期范围数据(读取；读取性能)……但对于写入来说却很糟糕。 (插入总是发生在平衡树的右侧，强制重新平衡，这是一项昂贵的操作)

显然... a) 了解您的数据。 b) 了解您的用例。 c) 了解您的数据库引擎。

但是，为高性能数据库定义合理模式的常识一般规则是什么？

Answer 1

好的，这里有一些关于索引生成的真正明确的建议:视情况而定。

这很清楚，但一点也不具体。如果您想要更具体的东西，则必须了解它依赖于什么。

这取决于您的 DBMS，甚至可能是您的 DBMS 的版本。这里有一些您应该了解的流行语，至少从表面上了解一下。我所说的“表面上”是指了解它对你有什么作用，以及它如何伤害你，但不一定了解它是如何工作的。如果可以获得，请使用特定于您的 DBMS 的文档。

避免全表扫描。

仅检索索引。

范围检索。 (以及复合或复合索引)

Merge Join(稍后讨论)。

哈希索引。

并发控制(稍后讨论)。

主键和索引(稍后讨论)。

索引更新的成本。

索引的延迟更新。

基于成本的优化。如果您的 DBMS 没有 CBO，则获取另一个 DBMS。

提示。 (如何使用它们，以及没有它们如何生活。)

数据库管理和 CBO。一些 DBMS 需要 DBA 定期操作以防止优化器使用过时的策略。

这取决于容量:对于非常小的表，索引设计相对微不足道。所谓“相对琐碎”，我的意思是它相当容易，但也相当不重要。犯错的代价很低。如果您正在构建查找表，您肯定需要代码列上的唯一索引。如果您将代码列声明为主键，您将得到这样一个表(对于大多数 DBMS)。如果您不创建任何其他索引，成本很可能是在一些延迟是可以容忍的异常情况下对小表进行表扫描。

任何模式中的大表往往是由例行事务处理添加的。这增加了拥有一些索引的好处，无论是在速度上还是在事务并发性方面。它还增加了拥有索引的成本，因为事务必须更新索引。成本效益权衡可能非常微妙，但对于交易表来说非常重要。

如果您的 DBMS 支持它，您可以对事务表上的某些索引使用延迟更新以取得良好效果。

在任何架构中，至少要尝试区分引用表和事务表。我知道，我知道，这有点主观。使用您的最佳判断。

这取决于流量:并非所有表都获得相同数量的流量。索引加速连接和查找。至少你应该了解你的 DBMS 是否有一个优化器知道如何根据可用的索引和表量进行合并连接。如果您不知道合并联接是什么，请了解它是什么。但是不要浪费时间学习如何编写合并连接程序，除非您以此为生。

这取决于紧急程度。在背景批处理期间每月执行一次的查询并不像每天等待用户 1000 次的查询那么紧急，而该用户正在盯着屏幕，或者上下文切换她的多任务处理。

当心产品营销会告诉您什么紧迫性。他们往往会告诉您，在任何情况下都比竞争对手更快是最紧迫的事情，即使这意味着您在错过第一个 child 的出生时还要在晚上和周末工作。营销通常不关心你是否精疲力竭。他们就像一个骑师，不在乎这匹马是否会再次比赛。事实上，有些交易非常紧迫，而另一些则相对不重要。

准备好灵活地设计索引，并考虑权衡取舍。

我希望我能为您推荐一本关于这个主题的好书。我希望其他人会这样做。