4. Message Queue 场景下的典型慢查询模式

在消息队列（Message Queue）系统中，数据库作为消息的持久化存储和状态管理后端，其查询性能直接影响消息的吞吐量和延迟。本章聚焦于消息堆积、批量拉取和死信队列三种典型场景，分析它们如何引发慢查询，并提供索引与连接池参数的优化策略。

4.1 消息堆积场景：索引选择性下降与全表扫描

当生产者发送消息的速度远高于消费者处理速度时，消息表（如 message_queue）会迅速堆积大量未消费记录。此时，针对 status = 'pending' 或 consume_time IS NULL 的查询，如果索引设计不当，极易退化为全表扫描。

-- 消费者拉取待消费消息
SELECT id, body, routing_key
FROM message_queue
WHERE status = 'pending'
  AND queue_name = 'order.paid'
ORDER BY created_at ASC
LIMIT 100;

索引失效原因分析：

• 索引前缀区分度低： 联合索引 (status, queue_name, created_at) 中，status 字段在堆积时大量记录均为 'pending'，导致索引第一列选择性极差，优化器可能放弃索引而选择全表扫描。
• 排序与过滤不匹配： ORDER BY created_at 需要文件排序（filesort），若索引无法同时满足过滤和排序，性能会急剧下降。
• LIMIT 偏移放大： 堆积深度大时，即使使用索引，也需要扫描大量行才能找到满足条件的记录。

4.2 批量拉取场景：IN 查询与连接池耗尽

消费者为了提高吞吐量，通常会批量拉取消息（例如一次拉取 500 条）。批量拉取在数据库层面通常表现为 WHERE id IN (...) 或 WHERE id BETWEEN ... AND ... 查询。当批量大小设置不合理时，会引发两类问题：索引使用不当和连接池资源争抢。

4.2.1 IN 列表过长导致索引失效

MySQL 优化器对 IN 列表的处理存在阈值。当 IN 列表中的值数量超过 eq_range_index_dive_limit（默认 200）时，优化器会从索引 dive 切换为索引统计信息估算，可能导致选择错误的索引或放弃索引。

4.2.2 连接池参数配置不当导致连接耗尽

批量拉取场景下，多个消费者线程同时从连接池获取连接执行查询。如果连接池最大连接数（max_connections）设置过小，或 wait_timeout 过长导致连接未及时释放，会引发连接池耗尽，新的查询请求排队等待，表现为应用层超时。

-- 推荐配置（高并发 MQ 场景）
max_connections = 500
wait_timeout = 60
interactive_timeout = 60
max_execution_time = 30000  -- 30秒查询超时

-- 避免配置
max_connections = 200        -- 过小，容易耗尽
wait_timeout = 28800         -- 8小时，连接泄漏风险高

4.3 死信队列场景：索引失效与数据倾斜

死信队列（Dead Letter Queue）用于存储消费失败或过期的消息。当大量消息进入死信队列时，查询模式发生变化：原本针对正常消息的索引不再适用，且死信消息通常带有 retry_count 或 error_code 字段，这些字段的基数低，容易导致索引失效。

4.3.1 死信查询的索引陷阱

典型的死信查询包括：

• 查询所有死信消息：WHERE status = 'dead'
• 按重试次数排序：ORDER BY retry_count DESC
• 按错误类型分组：GROUP BY error_code

这些查询的共同特点是：过滤条件基数极低（status = 'dead' 可能只占 1%），但排序或分组字段与过滤字段不匹配，导致索引无法覆盖。

4.3.2 数据倾斜导致索引统计偏差

死信队列中，某些错误类型（如 error_code = 'TIMEOUT'）可能占据绝大多数记录，导致索引统计信息严重偏斜。优化器基于过时的统计信息选择索引，可能做出错误决策。

4.4 综合优化清单

下表汇总了 Message Queue 场景下三种典型慢查询模式的优化要点：