mysql如何优化小表的查询索引_mysql全表扫描与索引代价对比

小表建索引需看执行计划而非经验；优化器会基于成本选择全表扫描或索引，重点观察EXPLAIN中的type和rows值，结合buffer pool命中率、统计信息是否更新及查询实际需求（如避免filesort、支撑JOIN）综合判断。小表要不要建索引？看执行计划比猜更靠谱小表（比如几百行）加索引不一定快，有时反而拖慢查询。MySQL 的优化器在评估 WHERE 条件时，会权衡「走索引 + 回表」和「直接全表扫描」的成本。当数据量小、缓存命中率高、或查询条件选择性差时，优化器大概率放弃索引——这不是 bug，是成本模型的合理判断。用 EXPLAIN SELECT ... 看 type 字段：如果是 ALL，说明走了全表扫描；ref/range 才算用了索引别只看「有没有索引」，重点看 rows 列：它反映优化器预估扫描行数，比实际行数还小？那索引很可能被跳过了SELECT * + 小表 + 无 WHERE 条件 → 几乎必然全表扫描，加索引纯属冗余哪些字段值得给小表加索引？不是所有 WHERE 都需要小表索引的价值不在“加速”，而在「避免临时排序/分组」或「支撑连接顺序」。比如 JOIN 中作为被驱动表，或 ORDER BY 字段没覆盖索引时触发 filesort。高频等值查询字段（如 status、type_id），且该字段在 WHERE 中出现频繁 → 值得建单列索引ORDER BY created_at LIMIT 10 这类查询，即使表只有 200 行，没索引也会触发 Using filesort复合索引要匹配最左前缀：(a, b) 能加速 WHERE a = ? 或 WHERE a = ? AND b = ?，但对 WHERE b = ? 无效注意隐式类型转换：比如 user_id 是 VARCHAR，但查询写成 WHERE user_id = 123（数字），索引会失效全表扫描真的慢吗？要看数据是否在 buffer pool 里小表全表扫描的物理 I/O 往往为 0，因为整个表可能早就被加载进 innodb_buffer_pool。这时扫描速度取决于内存带宽和 CPU，通常比走索引+回表更快——尤其当索引本身也得从磁盘读、且要多次随机 IO 时。 VWO 一个A/B测试工具