mysql - 插入/更新可扩展性(搜索越来越长的更新匹配列表是站不住脚的)

Question

这里还没有找到明确的答案。

我正在执行基本的“插入/更新”——将新数据汇集到“Tickets”的 MySQL 数据库中。

例如:

ticket_id: 154
status: open
messages: 2

这将是数据库中的一张票。

传入记录将根据 Ticket_id 插入/更新。也就是说，如果 Ticket_id 是新的，它将被插入，如果查找并找到它，它将被更新。为了进一步简化这一点，ticket_ids 按递增顺序依次递增。 Ticket_id 1 是第一张票，等等。

这是我的问题。现在我正在数据库中插入/更新 100,000 个 Ticket_ids。每个插入/更新写入(与纯插入不同)——必须对照 100,000 个 ID 查找每个传入 ID，以确定更新的潜在匹配项。每个月都会增加 60,000 个票据 ---- 直到最终在每次每日插入/更新期间“查找”超过 1,000,000 个票据_id。这是不可扩展的。事实上，对于大型 MySQL 数据库中的任何常规插入/更新来说，这似乎是一个极其常见的问题。

以下是潜在的好处:

1. Ticket_ID 是唯一的并按顺序增加
2. 票证状态变为:30 天不活动后已关闭。这意味着它们将永远不会再次更新。这是这里的关键。我不确定如何在插入/更新期间从技术上“忽略”这些票证，而无需每天“查找”它们。一种方法是每天或每月将“已关闭”的票证传输到单独的数据库表，并使用联合进行数据库查询。对此有何想法？无论如何，我都不是数据库管理员。

这就是答案吗？ 2 张 table ，还有票证存档？

而且...对 Ticket_ID 建立索引有好处吗？我听说这会增加写入时间，但会减少读取时间。

我认为，我现在的问题是为插入/更新编写时间，而不是 SELECT 语句。但有人告诉我，无论如何，插入/更新本质上都是一种选择/查找。

Answer 1

您应该做的第一件事是查看已有的索引

SHOW CREATE TABLE my_table_name\G

如果您的 UPSERT 变得越来越慢，向 Ticket_id 添加索引绝对是一个不错的起点。我建议你将其设为唯一索引。

CREATE UNIQUE INDEX my_index_name my_table_name (ticket_id);

添加索引确实会减慢插入速度，但对于每月有 60,000 条新记录、总共 1,000,000 条记录的数据库，您可能不会注意到。