Mariadb聚类索引设计问题

Question

下面是描述任务的表的关注列：

• Org_ID
• Task_ID
• Task_property_columns

对Task_ID的唯一要求是它对每个Org_ID都是唯一的，但是我不希望通过编程来处理它，并且它是自动递增的。

对Org_ID的要求是，我希望使用Org_ID组织的表使用排序操作来运行度量和分析，并在全国范围内移植一些任务属性。聚集在Task_ID上的表将是无用的，但是在Org_ID上生成是非常有益的。

从文档中可以看出，集群似乎是在MariaDB中为您选择的，它将在其中使用主键、唯一的非空索引或按该顺序自动生成的后台索引。

我对MariaDB非常陌生，我希望在选择正确的解决方案时能得到一些帮助。据我所知，我无法找到一个好的方式来自动增量和集群，我也希望它。

Answer 1

首先，澄清:本问题中的“集群”指的是PRIMARY KEY与数据的“集群”，而不是“服务器集群”。

您已经提供了InnoDB选择集群PK的3种选择。让我从用户的角度重新表述一下。

1. 如果您有一个列，或列的组合(所有非NULL)本质上是UNIQUE，那么使用它作为PK。这是一个“自然”的PK。
2. 如果选择1不可用，请使用AUTO_INCREMENT。
3. 虽然可用，但不要使用自动生成的隐藏PK的第三种选择。总有一天，您需要唯一地标识行，也许是为了维护。

与其他一些供应商不同，没有ROWNUM，也没有非集群PK。缺乏这些并不重要。

辅助键允许您以其他方式获取数据。辅助键包含PK的一个副本，以便它能够到达数据。PK和辅助键都组织为BTrees。BTree是最好的全方位索引方法；缺乏Hash等并不重要.

一个自然PK允许您对PK列进行范围扫描非常有效。

如果发现三分之二的表有“自然”的PK，那么只有三分之一的表需要auto_increment。

回到你的‘任务’。听起来你想

PRIMARY KEY(org_id, task_id)

但是希望task_id能够自动生成。这是可以通过说

task_id, INT UNSIGNED AUTO_INCREMENT NOT NULL

但是会有差距--因为auto_inc是表范围的，而不是特定于给定的org_id。如果你能忍受差距，那么这就是你的答案。

这是ENGINE=MyISAM中存在的一个特性。有关使用这的模拟，请参见InnoDB。

你说的是“国家移植”。您是否试图创建本地而不是集中生成的唯一ids？参见UUID和它的罪恶。

如果您正在总结大量数据，那么就构建和维护汇总表。

如果您想进一步讨论，请提供模式和查询的原型。