我的'projects'表中的每个条目都有一个唯一的32个字符的哈希标识符，使用varchar(32)存储。
将此作为primary key使用会被视为不良做法吗？主键有推荐的大小，数据类型吗？
答案 0 :(得分：5)
我会说是的，将这么大的列用作主键是个坏主意。原因是您在该表上创建的每个索引都将包含该32个字符的列，这将使所有索引的大小膨胀。更大的索引意味着更多的磁盘空间，内存和I / O.
如果可能，最好使用自动增量整数键，只需在哈希标识符列上创建唯一索引。
答案 1 :(得分：1)
取决于 tm ;）
根据您的描述判断，此字段是您的数据固有的，必须是唯一的。如果确实如此，那么必须使其成为关键。如果您有子表，请考虑引入另一个，所谓的“代理”键只是为了让孩子FK更苗条并且可能避免ON UPDATE CASCADE。但请注意，每个额外的索引都会引入开销，尤其是clustered tables。有关代理键的更多信息here。
另一方面，如果此键不是您的数据模型固有的，请将其替换为较小的键（例如自动递增的整数）。您将节省一些磁盘空间，并且（更重要的是）可以提高缓存的效率。
答案 2 :(得分：0)
取决于您对如何定义主键的使用。我通常使用INT（11）作为主键。它使外键非常容易。
我刚看到你的编辑。我个人会使用自动增量的int（11）。根据您的设置，这将允许您非常容易地让其他表具有外键约束。你可以用varchar做同样的事情，但我一直认为int比varchar更快，尤其是索引。
答案 3 :(得分：0)
使用它作为PKEY没有任何内在错误。如果你有许多其他表使用它作为FKEY，也许不是。没有人回答。
另请注意，如果您知道它总是正好是32个字符，那么您应该将其设为CHAR（32）。
答案 4 :(得分：0)
在数据库引擎中，最重要的项目之一是磁盘空间。通过减少数据库传输和传输的数据量，保持小而紧凑的数据通常与良好的性能相关联。如果一个表有几行，就没有理由定义INT类型的PK;可以使用MEDIUMINT，SMALLINT甚至TINYINT（就像使用DATE而不是DATETIME一样），这一切都是为了保持简洁。
答案 5 :(得分：0)
这个关键因为几个原因而不好。