我有一个字段是一个字母数字字段，理想情况下是一个非唯一标识符的加密字段。它用于以多对多关系关联其他相当大的事实表。我没有此字段的相关维度，因为此 FK 没有其他属性。
示例：Abcdefgh12345
该字段位于一个相当大且不断增长的数据仓库中，其中事实表按时间聚集而不是像这样在键上聚集。
该列VARCHAR(50)仅在 45 到 50 之间变化。必须检查，但我假设排序规则是SQL_Latin1_General_CP1_CI_AS. 出于优化原因，我不使用 FK。全部由 ETL 控制。
碎片化
由于键的类型，很难索引。它的碎片是通过我最近进行的一系列测试来管理的，这些测试显示 75% 的填充因子至少可以通过减少每日增量负载的碎片至少一周直到可能需要完全重建，每周一次就可以了。
表现
随着填充因子从 100% 降低到 75%，插入和读取变得更慢。记录也如预期的那样变大了。任何带有 include 的索引都在很大程度上推动了插入的性能，但当然可以帮助需要它们的查询提高 10 倍。
问题
有没有人有在数据仓库环境中使用字母数字的良好经验？它的处理方式和索引现在很好，但我认为它可能会更好。我正在考虑在 ETL 过程中剥离密钥、形成新维度并添加更易于管理的密钥的想法。
假设您关于
VARCHAR(50)使用排序规则的字段的假设是正确的SQL_Latin1_General_CP1_CI_AS，那么您应该考虑更改它存在的每个表中的那些字母数字“代码”字段，以具有排序规则Latin1_General_BIN2。由于该值来自算法，因此任何字母字符的大小写都应该一致，因此您无需担心不区分大小写的搜索。使用二进制排序规则将比非二进制排序规则（不区分大小写甚至区分大小写）执行得更好，因为它不需要处理任何具有文化意识的语言规则。此外，由于您已经尝试过
FILLFACTOR100 和 75 的设置并查看每种情况的优缺点，因此您应该尝试 90 的设置以查看是否有帮助。我会分别尝试每个更改（第一个，然后添加另一个），以便您可以单独测试它们的效果。这样你就知道每个变化的影响有多大。
我认为通常系统会受益于用 4 字节密钥替换 45 - 50 字节密钥（假设您使用
INT，因为这是维度数据，尽管即使是 8 字节BIGINT也会有所改进）。但是，添加一个新的维度表并将其切换VARCHAR(50)为一个INT（或BIGINT）需要同时更改数据模型和代码，而前两个更改仅影响数据模型，而且影响很小。