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