我有一个旧模式（免责声明！），它使用基于哈希生成的 id 作为所有表的主键（有很多）。这种 id 的一个例子是：
922475bb-ad93-43ee-9487-d2671b886479
改变这种方法是不可能的，但是索引访问的性能很差。撇开这可能的无数原因不谈，我注意到有一件事似乎不太理想 - 尽管所有许多表中的所有 id 值的长度都正好是 36 个字符，但列类型是varchar(36)，而不是 char(36)。
将列类型更改为固定长度是否会char(36)提供任何显着的索引性能优势，除了每个索引页的条目数量增加很小等之外？
即在处理固定长度类型时 postgres 的执行速度是否比处理可变长度类型快得多？
请不要提及微小的存储节省 - 与对列进行更改所需的手术相比，这无关紧要。
据我了解，第三范式（3NF）基本上意味着应该只有一个键。
如果带有自动增量id列的表也有一个已知的唯一且不为空的列，例如社会保险号，则此另一列可用作键。
忽略实际/业务问题（例如，在将 SSN 作为密钥/FK 传递时的安全性/隐私风险），从严格的模式设计方面来看，这样的表是否不会在 3NF 中，因为实际上有 2 个密钥？
答案是否会因另一列上是否有唯一键而有所不同？如果是这样，为什么？