MySQL事务表：是否使用自动增量键？答案

【问题标题】：MySQL transaction table : use auto increment key or not?MySQL事务表：是否使用自动增量键？
【发布时间】：2020-05-06 09:34:12
【问题描述】：

我正在寻找见解，因为我有点卡住了。

现在我在我的所有 MySQL innoDB 表中使用自动增量 ID。即使对于事务表（大容量表）也是如此。

在我的应用程序中，有人输入了一份财务日志，其中包含一些交易行，这些交易行保存在交易表中。

现在我收到用户希望能够更改这些交易而不是为该日记帐插入总更正并插入新行的需求请求。

我的程序没有问题，但我遇到了一个问题：如果该特定日记帐的交易行数发生变化怎么办？如果它们相同，我可以用它们已经拥有的当前自动增量 ID 覆盖这些行。

但是如果日志行比第一次插入时多或少怎么办？

当然，我可以删除所有以前插入的行并插入自动增量 ID 字段可以正常处理的新行。但它会在 ID 中留下空白。

我以前读过人们对我所说的差距的看法，从“别担心，你永远不会用完”到“哦，天哪，有问题”。

如果我在这个转换表中甚至不需要自动增量 ID，那么我是否会遗漏它？我总是通过日记号找到转表中的行，这是唯一的。

在此表上省略自动增量 ID 字段有什么缺点吗？

我能想到的只是它可能会减慢对该表的查询（我不确定），但想不出其他任何东西。

作为参考，我的 trans 表看起来有点像这样：

ID --> 自动递增 bigint
日志 --> int(11)
JournalLineNumber --> int(3)
说明 --> varchar (50)
金额 --> 小数
等等等等

顺便说一句，我仍然不知道如何在stackoverflow中的问题中插入诸如用于显示mysql表信息的表之类的东西，有人知道吗？刚才又用谷歌搜索了一遍，但似乎需要各种令人困惑的工具才能简单地输入信息表……但希望我错了。

【问题讨论】：

使用 auto_increment 编号来标识日志中的各个行很有用 - 例如，如果您想删除或更新没有其他方法来唯一标识的行，或者如果您希望包含运行总计等等等等。
为什么不简单地在需要新行时插入新行，并在更新时更新现有行？
你是对的，我很抱歉，我忘了提到我还有一个字段'linenumber'，它标识了期刊行号。很抱歉！！
@NicoHaase：当然，我现在就是这样做的。但这就是我问这个问题的原因：如果我使用自动增量 ID，它们会很快运行起来。当然，如果我使用 bigint，我不会很快用完 ID，但这就是我问的原因：我可以省略自动增量 ID，因为我认为不需要它
“跑起来”是什么意思？你说的是“几行”？

标签： mysql

【解决方案1】：

重要的是你有一个主键，而且它相当紧凑。 UUID 不是太大，因为它很大； bigint 很好。 int 很棒。如果您有 int 或 bigint 日记帐编号，则可以将其用作 PK，并且不需要 auto_increment。只要你有一个 PK 并且它不是很大，性能不会受到负面影响。

请注意，带符号的（默认）int(11) 仅适用于最多 2^31（~20 亿）。鉴于您的 auto_increment 是 bigint，您是否需要超过 -20 亿到 +20 亿的范围？是否应该为 0 到 40 亿不签名？在可预见的未来，40 亿是否足够？ 40 亿行的 ALTER TABLE 将需要 while。

粘贴SHOW CREATE TABLE 的输出。要将其显示为一个块，请确保每行至少有 4 个空格作为前缀。或者只是使用格式工具栏。

【讨论】：

'重要的是你有一个主键' - 是一个没有理由的陈述
相反，在 InnoDB 中最好有一个主键并且它是紧凑的，因为所有辅助键都是对主键的引用。如果您不定义一个，则会为您定义一个不可见的（因此您不妨通过显式定义它来保持对它的控制）。如果您使用的是基于行的复制，那么明确定义的主键就变得至关重要。 InnoDB 应该是存储引擎的首选，而基于行的复制应该是复制格式的首选。
我并不是说您在不解释原因的情况下发表声明并不是最佳做法。
必须假设一定数量的知识和谷歌搜索能力。否则，将这种逻辑得出结论将意味着通过粘贴整个 MySQL 文档集来回答每个 MySQL 问题。