大表查询慢的核心在于数据组织与访问路径不合理，优化需聚焦减少扫描行数、避免全表扫描、加快定位；应通过执行计划分析索引使用、遵循最左前缀建联合索引、慎用分页与拆分策略、查询瘦身及持续监控调优。
大表查询慢，核心问题往往不在SQL写法本身，而在数
据组织方式和访问路径是否合理。优化重点是减少扫描行数、避免全表扫描、加快定位速度。
加索引：先看执行计划，再建高效索引
用 EXPLAIN 查看查询是否走了索引、是否用了临时表或文件排序。重点关注 type（最好是 ref/const，避免 ALL）、rows（扫描行数越少越好）、Extra（避免 Using filesort / Using temporary）。
- 联合索引要遵循最左前缀原则，把高频过滤字段放前面，排序字段放最后
- 区分度高的字段更适合做索引，比如 user_id 比 status 更适合作为索引首列
- 避免过度索引，每个索引都会拖慢写入速度，且占用磁盘空间
- 对大表加索引建议在低峰期操作，MySQL 5.6+ 支持在线 DDL，但依然可能锁表或影响性能
分页优化：避免 limit 大偏移量
类似 SELECT * FROM order WHERE status=1 ORDER BY id LIMIT 100000, 20 这类语句，MySQL 仍需扫描前 100020 行才能返回结果，非常低效。
- 改用游标分页：记录上一页最大 id，下一页查 WHERE id > 12345 AND status=1 ORDER BY id LIMIT 20
- 对高并发分页场景，可预生成分页映射表，或用 ES 做检索层分担压力
-
前端限制最大页码，或提示“仅显示前 N 条”避免用户翻到极深页数
拆分策略：按业务或时间做水平切分
单表超千万行后，即使有索引，维护成本和查询抖动也会明显上升。
- 按时间归档：把历史订单表按月/年分表（order_202501、order_202502），常用查询只扫当月表
- 按业务维度分库分表：如用户中心、订单中心、日志中心各自独立数据库，减少单库压力
- 谨慎使用 ShardingSphere 等中间件，引入复杂度；优先考虑应用层路由 + 分表逻辑
- 冷热分离：把半年前的订单迁到 archive 库，主表只保留活跃数据
查询瘦身：只取需要的字段和数据
避免 SELECT *，尤其在大表 JOIN 或有 TEXT/BLOB 字段时，网络传输和内存消耗会剧增。
- 明确指定字段名，去掉无用列，尤其避开未建索引的大文本字段
- 用覆盖索引：把 SELECT 的字段都包含在索引中，让 MySQL 直接从索引获取数据，无需回表
- 用 EXISTS 替代 IN（尤其子查询结果集大时），IN 可能触发全表扫描
- 聚合类查询（COUNT/SUM）考虑用汇总表或定时任务预计算，而不是实时扫描大表
不复杂但容易忽略。优化不是一锤子买卖，得结合监控（慢日志、Performance Schema）、压测和业务增长节奏持续调整。
