大表查询慢的核心是执行路径错误，需从查询、索引、表结构、执行计划四层面优化：精简 select 和 WHERE 条件，按最左前缀建高效复合索引，确保主键与合理分区，结合 EXPLai N 定位 type/rows/Extra 瓶颈。
大表查询慢，核心不是“数据多”，而是“数据库 没走对路”。优化不是 堆硬件或盲目加索引，关键在理清执行路径、识别瓶颈、针对性干预。下面从查询、索引、表结构、执行计划四个层面拆解真实可用的优化逻辑。
查什么？先聚焦必要字段和条件
90% 的慢查询源于“SELECT *”和宽松 WHERE。大表中全字段扫描 + 无过滤条件 = 全表扫描，IO 和内存压力陡增。
- 只查真正需要的列，避免 隐式转换 （如用 字符串 匹配数字字段）
- WHERE 条件必须能命中索引：等值 > 范围 > 模糊前缀（LIKE ‘abc%’ 可用，’%abc’ 不行）
- 慎用 OR、函数包裹字段（如 WHERE YEAR(create_time) = 2024）、NOT IN —— 这些大概率导致索引失效
索引怎么建？按查询模式倒推，不是越多越好
索引是加速查找的“目录”，但目录太厚也拖慢翻页。重点看执行计划中的 type（最好是 ref/const，避免 ALL）和 key 列。
- 复合索引遵循最左前缀原则：WHERE a=1 AND b=2 AND c>3，索引 (a,b,c) 有效；(b,a,c) 或 (a,c) 效果打折
- 高区分度字段放左边（如 user_id > status），低基数字段（如 is_deleted=0/1）慎作索引首列
- 覆盖索引优先：SELECT id,name FROM t WHERE uid=123，有索引 (uid,name,id) 就不用回表，性能跃升
表结构是否合理？别让设计缺陷拖垮后期
大表性能问题，常埋在建表之初。比如用 TEXT 存短文本、没主键、字符集乱、分区缺失。
- 必须有显式主键（最好是自增 整型），否则 InnoDB 会生成隐藏 ROW_ID，影响写入和二级索引效率
- TEXT/BLOB 字段独立成扩展表，避免主表宽度过大，降低缓冲池命中率
- 单表超 2000 万行且有明显时间 / 业务分片特征（如订单按月），考虑 RANGE 分区或归档冷数据
执行计划怎么看？EXPLAIN 是你的诊断听诊器
不看执行计划就调优，等于蒙眼换轮胎。重点关注：type、key、rows、Extra（尤其是 using filesort / Using temporary）。
- type=ALL？立刻检查 WHERE 是否走索引、索引是否被干扰
- rows 远大于实际返回数？说明索引选择性差或统计信息过期（可 ANALYZE table 更新）
- Extra 出现 Using temporary：通常因 GROUP BY / DISTINCT 字段没索引，或 JOIN 关联方式不当
基本上就这些。优化不是一锤子买卖，而是“观察 → 定位 → 假设 → 验证 → 回滚 / 固化”的闭环。每次上线前用慢日志 + EXPLAIN 看一眼，比出问题再救火强十倍。
