使用“varchar”作为主键真的很糟糕吗？
（将存储用户文档，是的，它可能超过2亿个文档）
答案 0 :(得分：16)
完全取决于数据。有许多完全合法的情况，您可以使用VARCHAR主键，但如果有人可能希望在将来某个时候更新相关列的最远的机会，请不要使用它作为关键。
答案 1 :(得分：7)
如果要连接其他表，varchar（尤其是宽varchar）可能比int慢。
此外，如果您有许多子记录且varchar可能会发生变化，则级联更新可能会导致所有用户阻塞和延迟。像汽车VIN号码这样的varchar很少有变化，很好。像名字一样的varchar会发生变化，这可能是一场等待发生的噩梦。如果可能的话，PK应该是稳定的。
接下来很多可能的varchar Pks并不是唯一的，有时候它们看起来很独特（比如电话号码），但可以重复使用（你放弃号码，电话公司重新分配它），然后可以将子记录附加到错误的地方。因此，在使用之前，请确保您确实拥有独特的不变价值。
如果您决定使用代理键，则为varchar字段创建唯一索引。这可以让您获得更快的连接和更少记录的好处，如果某些内容发生变化，但仍保持您想要的唯一性。
现在，如果你没有子表，并且似乎永远都不会，那么大部分都没有实际意义并且添加整数pk只是浪费时间和空间。
答案 2 :(得分：2)
我意识到我在这里参加派对有点晚了，但是认为对以前的答案进行详细说明会有所帮助。
使用VARCHAR（）作为主键并不总是总是不好，但它几乎总是。到目前为止，我还没有遇到过无法找到更好的固定大小主键字段的时间。
VARCHAR需要比整数（INT）或短固定长度char（CHAR）字段更多的处理。
除了存储额外的字节，表示＆＃34;实际＆＃34;对于每个记录，在该字段中存储的数据长度，数据库引擎必须做额外的工作来计算每次读取之前字段的起始和结束字节的位置（在内存中）。
外键也必须使用与引用的父表的主键相同的数据类型，因此在连接表时输出更多的化合物。
使用少量数据，这种额外的处理可能不太明显，但随着数据库的增长，您将开始看到退化。
您说您使用GUID作为密钥，因此您提前知道该列具有固定长度。这是使用固定长度CHAR（36）字段的好时机，这会产生更少的处理开销。
答案 3 :(得分：1)
我认为int或bigint通常更好。
答案 4 :(得分：0)
使用ID（如果您只想显示50等，这将变得很方便......）。比使用文件名在varchar上设置约束UNIQUE（我假设，这就是你要存储的内容）。
这样做可以提高速度。