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