【问题标题】:Effect of a long char as a primary key [duplicate]长字符作为主键的效果[重复]
【发布时间】:2016-03-06 07:52:27
【问题描述】:

我正在计划一个包含小型会计科目表的数据库。我的帐户代码是这样的名称:

  • CURRENT_DEBTORS
  • CURRENT_CREDITORS
  • CASH_AT_BANK

我正在考虑将帐户代码用作帐户数据库中的主键,这意味着它将是事务表中的外键。该字段类似于 MySql 中的 CHAR(20)。交易表每月将获得大约 10,000 个条目。

这个冗长的字符索引将如何影响性能?如果我也有,我可以使用代理键,但也不希望。 (当然,我不太担心磁盘空间)。

【问题讨论】:

  • CHAR(20) utf8 吗?如果是这样,则需要 60 个字节。如果合适,请设为CHARACTER SET ascii
  • 有时“自然”PK 实际上比添加代理 AUTO_INCREMENT PK 更快更小。一个例子是没有辅助键时。

标签: mysql indexing


【解决方案1】:

从技术上讲,您的问题的答案是不会对性能产生巨大影响,但会产生一些影响,您需要在系统上对其进行测试才能了解真正的影响。

但实际上,答案是:不要那样做。将这些代码存储在一个表中,为每个代码指定一个唯一的整数 id(AUTO_INCREMENT 列)并将该整数设为您的外键。这已正确规范化,使用的空间比每行中额外的 CHAR(20) 少得多,并且对性能的影响要小得多。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2023-03-29
    • 2012-10-23
    • 1970-01-01
    • 2011-05-04
    • 1970-01-01
    • 1970-01-01
    • 2018-11-18
    • 2020-03-16
    相关资源
    最近更新 更多