我正在开发一个项目，要求我生成数十亿个唯一代码。目前我使用带有InnoDB引擎和python的MariaDB生成随机唯一代码，每个生成周期插入5000个唯一代码批次。
我的表结构：
row_id int --primary key + autoincrement
unique_code varchar(10) --unique
问题是：当我达到500.000.000-ish唯一代码时，插入变得非常慢，我仍然需要生成多达30亿个代码。在达到那么多记录之前，我可以在几个小时内插入3到4亿个唯一代码。
任何帮助将不胜感激，谢谢！
更新（1919年1月22日）回答Rick James的解决方案。以下是生成代码的一些示例：
RLXT$CPS1Y
Y4P$9K70WO
PKSTY9M$FR
T$0VEFL2B1
RX4$MEKVQL
我的服务器有32GB的RAM和相对较快的SAS硬盘，我认为它足以满足我的需求（或者它不是？）。
根据我的经验，TokuDB在插入100m记录之前插入速度较慢并且很难，所以我当时就去了InnoDB。
至于我前面提到的交易：是的，一次插入5000条记录。直到150米的代码才这么快，之后我注意到随着记录的增长，速度逐渐下降。现在我要达到800米的代码，插入周期需要10到15秒（5000个记录）。
我使用autoincrement id对记录进行排序和标记，因为这些代码将被转移到另一个数据库进行打印（生产）。所以我需要知道哪些代码已经转移，哪些代码没有转移。
我会等待进一步的答复，同时我会尝试Rick's suggestions。谢谢！
向我们展示一个例如前10个值的样本。
这就是你可能“碰壁”的原因......索引可以归类为（在某个级别）两种风格：
AUTO_INCREMENT值，或TIMESTAMPs，您按时间顺序插入行，或甚至按时间顺序插入行。这些值插入表或索引的“结尾”，并仅命中BTree的最后一个块（或几个块）。通过仅在几个块中进行所有活动，执行的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();
这是如何执行：
INSERT他们进入real表，创建顺序ids。注意：这将创建一个巨大的撤销表，因此请确保有大量磁盘空间。
至于我关于放弃id，UNIQUE等的评论，请提供有关您打算如何使用real的信息，以便我同意或反对他们的需要。
另一个计划
不要预先生成值。相反，从大约14T可能的值生成一个新值，检查重复，必要时生成另一个。在这个计划中，表格会根据需要逐渐增长，而不是最初需要努力构建它。相反，只要需要新值，就会花费很少的精力（毫秒）。这可以包含在存储功能中，以方便用户使用。
该表只有一列，unique_code CHAR(10) CHARSET ascii PRIMARY KEY。
试试MySQL INDEXES（如果您的服务器配置不太好，必须升级ram大小等）