有人问了这个问题：“INT, BIGINT or UUID/GUID in Oracle, DB2, Derby and HSQLDB?”我开始思考我设计的所有数据库模式以及我读过的书籍，而不是一个参考文献给出了任何真实的 明确关于创建索引的建议。
例如;如果您有像
这样的复合索引date() ++ foo() ++ bar()
虽然这个索引很适合搜索和排序日期范围数据（读取;读取性能）......但写入很糟糕。 （插入总是发生在平衡树的右侧，迫使重新平衡，这是一项昂贵的操作）
显然...... a）知道你的数据。 b）了解你的用例。 c）了解您的数据库引擎。
但是为高性能数据库定义合理模式的常识一般规则是什么？
答案 0 :(得分：4)
好的，这里有一些关于索引生成的明确建议：它取决于。
这很明显，但根本不具体。如果你想要更具体的东西，你必须了解它所依赖的东西。
这取决于您的DBMS，甚至可能是您的DBMS版本。以下是您应该了解的一些流行语，至少表面上看。通过“表面上”我的意思是了解它为你做了什么，以及它如何伤害你，但不一定是它如何运作。使用特定于DBMS的文档，如果可以的话。
避免全表扫描。
仅索引检索。
范围检索。 （以及复合或复合索引）
合并加入（稍后讨论）。
哈希索引。
并发控制（稍后讨论）。
主键和索引（稍后讨论）。
索引更新的成本。
索引的延迟更新。
基于成本的优化。如果您的DBMS没有CBO，那么请获取另一个DBMS。
提示。 （如何使用它们，以及如何在没有它们的情况下生活。）
数据库管理和CBO。某些DBMS需要定期执行DBA操作，以防止优化程序使用过时的策略。
这取决于数量：对于非常小的表，索引设计相对微不足道。通过“相对微不足道”，我的意思是它相当容易，但它也相当不重要。错误的代价很低。如果您正在构建查找表，那么您肯定需要代码列上的唯一索引。如果将代码列声明为主键，您将获得这样一个表（包含大多数DBMS）。如果您不创建任何其他索引，则在可以容忍某些延迟的特殊情况下，成本很可能是对小表的表扫描。
任何模式中的大表往往是通过例程事务处理添加的表。这增加了在速度和事务并发方面具有一些索引的好处。它还增加了索引的成本，因为事务必须更新索引。成本效益权衡可能非常微妙，对交易表非常重要。
如果您的DBMS支持它，您可以使用延迟更新，以便在事务表上使用某些索引。
在任何模式中，至少尝试将参考表与事务表区分开来。我知道，我知道，这有点主观。用你最好的判断。
这取决于流量：并非所有表都获得相同的流量。索引可以加快连接和查找速度。至少，您应该了解您的DBMS是否有一个优化器，它知道如何根据可用索引和表卷进行合并连接。 如果您不知道合并连接是什么，请了解它是什么。但是，不要浪费时间学习如何编写合并加入，除非这是你为生活所做的事情。
这取决于紧迫性。在beckground批处理期间每月执行一次的查询不像每天1000次查看用户的查询那样紧急，而该用户盯着屏幕，或上下文切换她的多任务处理。
谨防产品营销会告诉您紧急情况。他们倾向于告诉你，比竞争对手更快，在每种情况下都是最紧迫的，即使这意味着在你错过第一个孩子出生的同时工作的晚上和周末。营销往往不关心你是否被烧毁。他们就像一个骑师，不关心这匹马是否再次比赛。事实是，有些交易非常紧急，而其他交易则相对不重要。
准备好对指数设计保持灵活性，并考虑权衡利弊。
我希望我能指出一本关于这个主题的好书。我希望别人会这样做。
答案 1 :(得分：3)
创建索引只有几条经验法则：
应该根据应用程序的性能问题添加其他索引
在最后一句中，您说“定义合理的架构”。这比设计索引要普遍得多。