5

我表中的每个条目'projects'都有一个唯一的 32 个字符的哈希标识符，使用varchar(32).

将其用作primary key? 是否有推荐的主键大小和数据类型？

4

6 回答 6

5

我会说是的，将这么大的列用作主键是个坏主意。原因是您在该表上创建的每个索引都将包含 32 个字符的列，这会使所有索引的大小膨胀。更大的索引意味着更多的磁盘空间、内存和 I/O。

如果可能，最好使用自增整数键，并简单地在哈希标识符列上创建唯一索引。

于 2012-12-21T20:13:00.500 回答
1

取决于tm ;)

从您的描述来看，此字段是您的数据所固有的，并且必须是唯一的。如果确实如此，那么您必须将其设为密钥。如果您有子表，请考虑引入另一个所谓的“代理”键，以保持子 FK 更苗条，并可能避免 ON UPDATE CASCADE。但请注意，每个额外的索引都会引入开销，尤其是对于聚簇表。更多关于代理键的信息。

另一方面，如果此键不是数据模型固有的，请将其替换为较小的键（例如，自动递增的整数）。您将节省一些磁盘空间并（更重要的是）提高缓存的有效性。

于 2012-12-21T21:50:05.407 回答
0

这个键不好有几个原因。

  • @Eric 解决了一个问题，因为每个二级索引都将包含相同的 32 个字符
  • 主键往往用于从其他表中查找，并且这些表也需要有这 32 个字符，也许在那里主键和同样的问题会在这些表上再次出现。
  • 我能想到的最大原因是性能。当您插入散列类型的记录时，您基本上是以随机顺序插入键，这反过来最终会导致大量页面拆分和仅填充 50% 到 90% 的页面。这会导致不必要的深度树、更长的搜索时间、更大的表空间以及索引占用更多内存。
于 2012-12-21T20:42:09.273 回答
0

取决于您对如何定义主键的用法。我通常使用 INT(11) 作为主键。它使外键变得非常容易。

我刚看到你的编辑。我个人会使用带有自动增量的 int(11)。根据您的设置，这将允许您非常轻松地拥有具有外键约束的其他表。你可以用 varchar 做同样的事情，但我一直认为 int 比 varchar 快，尤其是索引。

于 2012-12-21T20:12:28.440 回答
0

将其用作 PKEY 本身并没有错。如果您有许多其他表将其用作 FKEY，则可能不会。没有一个答案。

另请注意，如果您知道它总是正好是 32 个字符，则应该改为 CHAR(32)。

于 2012-12-21T20:13:10.500 回答
0

在数据库引擎中，最重要的项目之一是磁盘空间。通过减少数据库传输和传输的数据量，保持小而紧凑的数据通常与良好的性能相关联。如果表将有几行，则没有理由定义 INT 类型的 PK。可以使用 MEDIUMINT、SMALLINT 甚至 TINYINT（就像使用 DATE 而不是 DATETIME 一样），这一切都是为了保持简洁。

于 2012-12-21T20:18:42.490 回答