是否有可能加快 WHERE IN 或用更快的替代方案替换它？

Question

我正在尝试在下面的查询中加快选择速度，WHERE IN 中有超过 1000 个项目

表：

CREATE TABLE `user_item` (
  `user_id` int(11) unsigned NOT NULL,
  `item_id` int(11) unsigned NOT NULL,
  PRIMARY KEY (`user_id`,`item_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

查询：

SELECT
    item_id
FROM
    user_item
WHERE
    user_id = 2
    AND item_id IN(3433456,67584634,587345,...)

IN 列表中有 1000 个项目，执行查询大约需要 3 秒。在这种情况下可以进行任何优化吗？此表中可能有数十亿行。是否可以通过其他数据库或编程方法更快地执行此操作？

更新：

解释的结果如下：

如果我在 IN(...) 语句中有 999 个项目：

+------+-------------+----------+-------+---------------+---------+---------+------+------+--------------------------+
| id   | select_type | table    | type  | possible_keys | key     | key_len | ref  | rows | Extra                    |
+------+-------------+----------+-------+---------------+---------+---------+------+------+--------------------------+
|    1 | SIMPLE      | user_item | range | PRIMARY       | PRIMARY | 8       | NULL |  999 | Using where; Using index |
+------+-------------+----------+-------+---------------+---------+---------+------+------+--------------------------+

如果我在 IN(...) 语句中有 1000 个项目：

+------+--------------+-------------+--------+---------------+---------+---------+--------------------+------+--------------------------+
| id   | select_type  | table       | type   | possible_keys | key     | key_len | ref                | rows | Extra                    |
+------+--------------+-------------+--------+---------------+---------+---------+--------------------+------+--------------------------+
|    1 | PRIMARY      | <subquery2> | ALL    | distinct_key  | NULL    | NULL    | NULL               | 1000 |                          |
|    1 | PRIMARY      | user_item    | eq_ref | PRIMARY       | PRIMARY | 8       | const,tvc_0._col_1 |    1 | Using where; Using index |
|    2 | MATERIALIZED | <derived3>  | ALL    | NULL          | NULL    | NULL    | NULL               | 1000 |                          |
|    3 | DERIVED      | NULL        | NULL   | NULL          | NULL    | NULL    | NULL               | NULL | No tables used           |
+------+--------------+-------------+--------+---------------+---------+---------+--------------------+------+--------------------------+

更新 2

我想解释一下为什么我需要在上面做：

我想让用户能够列出按 sort_criteria_1、sort_criteria_2 或 sort_criteria_3 排序的项目，并从列表中排除那些在 user_item 表中由给定 (n) 个用户标记的项目。

这是示例架构：

CREATE TABLE `user` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(45) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE `item` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `file` varchar(45) NOT NULL,
  `sort_criteria_1` int(11) DEFAULT NULL,
  `sort_criteria_2` int(11) DEFAULT NULL,
  `sort_criteria_3` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_sc1` (`sort_criteria_1`),
  KEY `idx_sc2` (`sort_criteria_2`),
  KEY `idx_sc3` (`sort_criteria_3`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE `user_item` (
  `user_id` int(11) NOT NULL,
  `item_id` int(11) NOT NULL,
  PRIMARY KEY (`user_id`,`item_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

以下是我如何获取按 sort_criteria_2 排序的项目，不包括 user_item 表中用户（300、6、1344、24）记录的项目：

SELECT
    i.id,
FROM
    item i
    LEFT JOIN user_item ui1 ON (i.id = ui1.item_id AND ui1.user_id = 300)
    LEFT JOIN user_item ui2 ON (i.id = ui2.item_id AND ui2.user_id = 6)
    LEFT JOIN user_item ui3 ON (i.id = ui3.item_id AND ui3.user_id = 1344)
    LEFT JOIN user_item ui4 ON (i.id = ui4.item_id AND ui4.user_id = 24)
WHERE
    ui1.item_id IS NULL
    AND ui2.item_id IS NULL
    AND ui3.item_id IS NULL
    AND ui4.item_id IS NULL
ORDER BY
    v.sort_criteria_2
LIMIT
    800

上述方法的主要问题是我过滤的用户越多，查询的成本就越高。我希望客户端浏览器支付过滤费用。因此，我会将每个用户的项目列表和匹配的 user_item 记录列表发送到客户端进行过滤。这也有助于分片，因为我不必在同一台机器上拥有 user_item 表或记录集。

Answer 1

很难准确判断，但由于有许多恒定的item_id 值，解析庞大的查询可能会有延迟。

1. 您是否尝试过仅获取 user_id 的所有值？由于该字段是PRIMARY KEY 中的第一个（主）字段，因此仍将使用相关索引。

2. 您是否尝试过用子查询替换常量列表？例如，您可能对特定类型的项目感兴趣。

3. 确保您使用Prepared statement 概念 - 至少在您的数据库和语言支持的情况下。这将保护您的代码免受可能的 SQL 注入并启用数据库内置查询缓存（如果您的数据库支持）。

Answer 2

您可以将它们放入带有索引的临时表中，然后将其与user_item-table 连接，而不是将 1000 个 item_id 放入 IN-clause。

如果您还拥有一个同时包含user_id 和item_id 的索引，这将使查询变得最快。其余的取决于数据分布。