数亿数据后 MySQL/MariaDB 插入速度慢答案

【问题标题】：Slow MySQL/MariaDB insert after hundreds of million data数亿数据后 MySQL/MariaDB 插入速度慢
【发布时间】：2019-01-21 04:06:05
【问题描述】：

我正在从事一个需要生成数十亿个唯一代码的项目。目前我使用 MariaDB 和 InnoDB 引擎和 python 来生成随机唯一代码，每个生成周期插入 5000 个唯一代码。

我的表结构：

row_id int              --primary key + autoincrement
unique_code varchar(10) --unique

问题：当我达到 500.000.000 个唯一代码时，插入变得非常慢，我仍然需要生成多达 30 亿个代码。在达到这么多记录之前，我可以在几个小时内插入 300-4 亿个唯一代码。

任何帮助将不胜感激，谢谢！

更新（2019 年 1 月 22 日） 回答Rick James'的解决方案。以下是一些生成代码的示例：

RLXT$CPS1Y
Y4P$9K70WO
PKSTY9M$FR
T$0VEFL2B1
RX4$MEKVQL

我的服务器有 32GB 的 RAM 和相对较快的 SAS 硬盘，我认为这足以满足我的需求（或者不是？）。

根据我的经验，TokuDB 的插入速度较慢，并且在达到 1 亿条记录之前很困难，所以我当时去了 InnoDB。

关于我之前提到的事务：是的，一次插入 5000 条记录。直到150m的代码都非常快，之后我注意到随着记录的增加速度逐渐下降。现在我要编写 800m 的代码，插入周期（5000 个记录）需要 10 到 15 秒。

我使用自动增量 ID 对记录进行排序和标记，因为这些代码将被转移到另一个数据库进行打印（生产）。所以我需要知道哪些代码已经转移，哪些没有。

我会等待进一步的答复，同时我会尝试Rick's suggestions。谢谢！

【问题讨论】：

你在使用事务吗？
我是。我也尝试过不同的存储引擎（MyISAM、TokuDB、XtraDB），但仍然没有找到解决方案

标签： python mysql mariadb innodb

【解决方案1】：

向我们展示前 10 个值的样本。

这就是您可能“碰壁”的原因...索引可以（在一定程度上）分为两种类型：

连续，例如AUTO_INCREMENT 值或TIMESTAMPs，您可以在其中按时间顺序插入行，甚至按时间顺序插入行。这些值被插入到表或索引的“末尾”，并且只命中 BTree 的最后一个块（或几个块）。由于只在几个块中完成所有活动，因此需要执行的 I/O 很少。
随机，例如 UUID、MD5 和其他“随机”值，大概包括您的值。在这种情况下，插入表/索引的“下一个”值不太可能仍缓存在 RAM 中。所以需要I/O。虽然表不是太大，但所有索引块都可以保存在 RAM 中，因此需要很少的 I/O。但是在索引增长到大于缓存之后，添加“下一个”值的行为通常需要进行 I/O。你的进程会越来越慢。

怎么办？

计划 A：在插入所有行之后添加“随机”索引。添加索引会很慢，但从长远来看可能会更快，因为它可以使用不同的算法。

B 计划：不要预先创造所有的价值。而是在需要时创建下一个。

计划 C：购买足够的 RAM 以将“随机”索引完全保存在 RAM 中。（计划有大约 2 倍的索引大小。）

计划 D：您尝试过 TokuDB 吗？我希望它在陷入严重麻烦之前能够存活更长时间。你的经历是什么。

您提到了交易。请详细说明。您的意思是每 5000 个代码在交易中都是 INSERTed 吗？这可能是最佳选择。

您的唯一编号使用什么字符集和排序规则？您可能应该使用 ascii 和 ascii_bin -- 以提高速度并避免大小写问题。

而且...这是关于如何生成它们的另一种想法。无需在进行过程中检查唯一性，因为它们会生成唯一的：

将 10 个字符的字符串想象成以 base-95 整数编码的数字。（或者你允许的许多不同的字符）。我们将按顺序生成数字，将它们转换为字符串，然后将它们随机化。

“下一个”值计算为“当前”值之后的随机值。随机值需要介于 1 和大约十亿的增量之间（这取决于您最终想要多少个数字、字符集等）

INSERT 将 5K（或其他）批次放入没有索引的 MyISAM 表中。

完成后，执行以下操作：

CREATE TABLE real (
    id ... AUTO_INCREMENT, -- do you really need this??
    random CHAR(10), NOT NULL CHARSET ascii COLLATE ascii_bin,
    PRIMARY KEY(id),   -- what for?
    INDEX(random)   -- uniqueness has been checked
INSERT INTO real (random)
    SELECT random FROM myisam_table
        ORDER BY RAND();

这是如何执行的：

从本质上是一个平面文件（MyISAM 表）中获取所有“随机”字符串。
使用 unix 排序来打乱它们。
INSERT 将它们添加到 real 表中，从而创建连续的 ids。

注意：这将创建一个巨大的撤消表，因此请确保有大量磁盘空间。

至于我的cmets关于放弃id、UNIQUE等，请提供您打算如何使用real的信息，以便我同意或反对他们的需求。

另一个计划

不要预先生成值。相反，从大约 14T 的可能值中生成一个新值，检查重复，如有必要，再生成另一个。在这个计划中，表格会根据需要逐渐增长，而不是一开始就必须努力构建它。相反，每当需要新值时，都会花费一些精力（毫秒）。这可以包装在存储函数中，以方便用户使用。

该表将只有一列，unique_code CHAR(10) CHARSET ascii PRIMARY KEY。

【讨论】：

感谢您提供非常有用的答案，非常感谢。我更新了我上面的帖子来回答你的问题
@Dhemas - INT 将在 20 亿之后用完。 INT UNSIGNED 将在 40 亿之后用完。如果你需要的比你拥有的更多，你也可以现在停止并修复它。
@Dhemas - 您描述的减速与 UNIQUE 索引（BTree）的缓存耗尽一致。 innodb_buffer_pool_size 的值是多少？
@Dhemas - 如果我可以调整你的算法去保证所有的值都是不同的；你能摆脱唯一性约束吗？也许甚至摆脱索引？
对不起，我忘了提，我已将表中的 INT 更改为 BIGINT UNSIGNED。 innodb_buffer_pool_size 设置为 16G

【解决方案2】：

试试 MySQL INDEXES（如果你的服务器配置不太好必须升级内存大小等）

【讨论】：