小表查询慢主因是锁阻塞、索引未生效或执行计划失真；需先查processlist定位长事务和锁等待，再用explain验证索引使用，结合性能指标分析热点与并发瓶颈。
表数据量不大但查询极慢，大概率不是数据多导致的，而是索引没用上、锁被卡住、或执行计划严重失真——先别急着加索引或调配置，得把这几类“小表大堵点”揪出来。
查 SHOW FULL PROCESSLIST 看有没有卡住的事务
小表查询慢，最常被忽略的是“前面有人没走完”。比如一个未提交的事务在更新某条记录，后续所有读该行的 SELECT ... FOR UPDATE 或普通 SELECT（在 RC 隔离级别下也可能因 gap lock 被阻塞）都会等它释放锁。
-
State列显示Locked、Waiting for table metadata lock或Waiting for row lock就是典型信号 - 重点关注
Time值大的线程，再用SELECT * FROM performance_schema.events_statements_current WHERE THREAD_ID = xxx查它在执行什么 - 如果发现长事务（比如几十秒没提交），直接
KILL掉并推动业务层修复事务边界
用 EXPLAIN 确认是否真走了索引
“表只有 1 万行，怎么还全表扫描？”——常见于索引列被隐式转换、函数包裹、或联合索引没按最左前缀使用。
-
key为NULL或type = ALL是硬指标，说明没走索引 - 检查
WHERE条件：字符串字段传了数字（如phone = 13800138000）、时间字段用了DATE(create_time)、模糊查询写成LIKE '%abc' - 联合索引
idx_user_status_ctime(user_id, status, create_time)，如果只查WHERE status = 1，索引完全失效
盯紧 Threads_running 和 InnoDB_row_lock_waits
即使单条 SQL 很快，高并发下锁竞争也会让响应时间雪球式增长。小表反而更容易成为热点，比如用户登录态表、配置表、计数器表。
- 执行
SHOW GLOBAL STATUS LIKE 'Threads_running'，持续 >32 就说明有大量查询在排队等资源 - 对比
InnoDB_row_lock_waits和InnoDB_row_lock_time_avg：后者超过 10ms 就值得警惕，说明锁等待已成瓶颈 - 这类问题往往伴随
Handler_read_rnd_next指标飙升（随机 IO 次数暴增），因为锁等待导致查询被迫重试或回退
检查 long_query_time 设置是否合理
阈值设太高（比如默认 10 秒），会让“慢”变得不可见；设太低（比如 0.1 秒），日志爆炸且掩盖真正问题。对小表来说，0.5 秒是更合理的起点。
- 临时调整：
SET GLOBAL long_query_time = 0.5，注意新连接才生效 - 立刻查
slow_query_log_file路径，用mysqldumpslow -s t -t 5 /path/to/slow.log看总耗时最高的前 5 条 - 特别留意那些“单次不慢但每秒执行几百次”的 SQL，它们才是拖垮小表响应的隐形推手
小表慢的本质，往往是局部热点 + 锁 + 索引误用三者叠加。比起盲目建索引，优先确认锁状态和执行计划是否真实可靠——很多 case 最后发现只是某条 SQL 多了个空格导致执行计划缓存错乱，或者应用层没关自动提交，让事务意外持锁十几秒。
