我有一个大表，其 ID 列设置为 bigint auto_increment。在历史上的某个时候，我们决定在客户端生成一些伪随机数的 ID。
我的问题很简单:鉴于表列仍设置为 auto_increment，即使我们始终在 INSERT 查询中提供 ID，这是否会对性能产生负面影响？这很重要/我应该费心去改变架构吗？ table 非常大而且繁忙，恐怕我无法在不停机的情况下完成此操作。
最佳答案
相信数据库会在大多数情况下为您提供“最佳”结果。有很多代码(至少在 InnoDB 中)可以使 AUTO_INCRMENT 快速高效，即使多个连接插入到同一个表中也是如此。
关于 AUTO_INCRMENT 和自行开发的 ID 的注释:
AUTO_INCRMENT可能会受到较少的锁定延迟和死锁的影响。- 我不会专注于主键进行优化；看看别处。
- 提供您自己的 ID 意味着您必须将其发送到服务器；这会增加(少量)带宽和延迟。
SELECT LAST_INSERT_ID()成本并不高，并且与连接隔离。也就是说，避免了一类竞争条件。- 如果您向 auto_inc 列提供数字，您就会破坏它的许多优化。
- 您有第二列包含您生成的 ID 吗？也就是说，您是否同时拥有
PRIMARY KEY和UNIQUE键？如果是这样，那就是开销，特别是对于必须处理所有唯一键的INSERT。 - “一些伪随机数”——如何处理偶尔出现的重复项？
- “非常忙”是什么意思？如果这主要是影响社交媒体“喜欢”的计数器，那么将该列移动到并行表(“垂直”分区)可能会提供显着的整体优化。
请提供SHOW CREATE TABLE以及针对该表的主要查询(读取和写入)。这将有助于集中此问答以更好地帮助您。
要更改主键需要停机。 (我认为即使使用 MySQL 8.0 的新 ALTER 优化也是如此。)
关于mysql - 与不使用 auto_increment 相比，使用 auto_increment ID 是否会降低性能？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/59392383/