MySQL主键查询全表扫描问题解析与优化

1. 问题现象：主键查询为何全表扫描？

上周排查一个线上慢查询问题时，遇到个有意思的案例：某个根据主键ID查询的简单SQL，执行时竟然走了全表扫描。表数据量在200万左右，全表扫描导致查询耗时从毫秒级暴涨到秒级。更诡异的是，这个SQL在测试环境执行计划完全正常。

问题SQL非常简单：

sql复制SELECT * FROM user_info WHERE user_id = '10086';

user_id字段是表的主键，数据类型为varchar(32)，存储的是字符串形式的用户ID。表结构如下：

sql复制CREATE TABLE `user_info` (
  `user_id` varchar(32) NOT NULL,
  `user_name` varchar(64) DEFAULT NULL,
  -- 其他字段...
  PRIMARY KEY (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

2. 排查过程：从执行计划到字符集

2.1 执行计划分析

首先用EXPLAIN查看执行计划，关键信息如下：

确实走了全表扫描（type=ALL），没有使用主键索引。但同样的SQL在测试环境执行计划是：

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
|----|-------------|