MySQL 5.7 大表查询慢主因是索引设计不当与执行计划偏差，应优先用 EXPLAIN 分析 type、rows、Extra 等字段，结合覆盖索引、最左前缀原则及更新统计信息（ANALYZE TABLE）优化，而非调参或重建表。
MySQL 5.7 大表查询慢，八成是索引没用对、执行计划走歪了，而不是硬件或配置问题。先别动 my.cnf，直接从 SQL 和索引入手——这是成本最低、见效最快的路径。
查不到执行计划就别谈优化
所有“为什么加了索引还慢”的问题，根源都在没看 EXPLAIN 输出。不跑一遍 EXPLAIN，你连问题出在扫描方式（type=ALL 还是 range）、是否回表（Extra 里有没有 Using filesort 或 Using temporary）都判断不了。
- 必须在和生产一致的库上执行，且表数据量要接近真实规模（小表上
EXPLAIN可能骗人） - 注意
key列是否命中你建的索引；rows值是否远超预期返回行数 - 如果
filtered值极低（比如10.00），说明索引区分度差，可能需要调整字段顺序或加前缀长度 -
Extra出现Using index condition是正常；出现Using where; Using index是覆盖索引；但凡带Using filesort，就得立刻盯住ORDER BY字段是否在索引中、方向是否匹配
联合索引必须按最左前缀+查询频率排序
MySQL 5.7 不支持降序索引，所以联合索引字段顺序不是“业务逻辑顺序”，而是“WHERE 条件出现频率 + 排序需求”的硬排序。错一位，整个索引就废一半。
- 高频等值条件放最左（如
order_status = 1），范围条件（BETWEEN、>）放右边（如create_time） - 如果查询同时有
WHERE a = ? AND b > ? ORDER BY c DESC，5.7 下c加进索引也白搭——它无法利用降序，ORDER BY c DESC必触发filesort - 避免冗余单列索引：
INDEX(a)和INDEX(a,b)共存时，前者基本无效，删掉 - 字符串字段建索引慎用全字段：
VARCHAR(255)直接建索引会拖慢写入，优先试INDEX(col(191))（UTF8MB4 下 191 字符 ≈ 764 字节，满足前缀索引限制）
覆盖索引不是可选项，是必选项
大表查询一旦回表，I/O 成倍增加。5.7 的 InnoDB 主键聚簇索引决定了：只要 SELECT * 或选了非索引字段，就一定回表。这不是性能“打折”，是直接“翻车”。
- 把
SELECT *改成只查真正需要的字段，再配合联合索引，让所有字段都落在索引 B+ 树叶子节点里 - 示例：查订单状态为 1 且时间在某区间的订单号和金额，建索引
INDEX(order_status, create_time, order_no, total_amount)，查询写成SELECT order_no, total_amount FROM orders WHERE order_status = 1 AND create_time > '2026-01-01' - 注意：
WHERE条件字段必须包含在索引最左部分，否则覆盖失效 - 如果业务真要
SELECT *，又无法改 SQL，考虑用生成列（generated column）+ 覆盖索引，但 5.7 需升级到 5.7.6+ 且仅支持虚拟生成列
别信“重建表就能快”，先看数据分布和统计信息
OPTIMIZE TABLE 对大表是高危操作：锁表、耗 I/O、可能失败。5.7 默认的 innodb_stats_persistent 关闭时，表统计信息过期会导致优化器选错执行计划——这才是很多“明明有索引却不用”的真相。
- 先运行
ANALYZE TABLE table_name更新统计信息，比OPTIMIZE安全百倍 - 确认是否启用了持久化统计信息：
SHOW VARIABLES LIKE 'innodb_stats_persistent'，建议设为ON并调大innodb_stats_persistent_sample_pages（默认 20，大表建议 100+） -
OPTIMIZE TABLE仅在以下情况必要：表经历过大量 DELETE/UPDATE 导致碎片率极高（DATA_FREE / DATA_LENGTH > 0.3），且业务允许短时锁表 - 线上大表禁用
ALTER TABLE ... ENGINE=InnoDB类重建操作，改用pt-online-schema-change或 5.7 原生的ALGORITHM=INPLACE在线加索引
真正卡住大表查询的，往往不是单点技术，而是索引字段顺序与查询模式错配、统计信息陈旧、以及盲目信任 SELECT * 的惯性。5.7 没有降序索引、没有直方图、优化器也不够智能——这意味着每一条慢查背后，都需要你亲手验证执行路径，而不是依赖配置或工具自动修复。
