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

张开发
• 2026/4/10 20:58:51 • 15 分钟阅读

最新文章

推荐文章

相关文章

分享文章

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测试工具

更多文章