大表查询慢，核心问题往往不在SQL写法本身，而在数据组织方式和访问路径是否合理。优化的关键是减少扫描行数、避免全表扫描、让查询尽可能走索引，并控制返回结果集大小。
加好索引，但别乱加
不是所有字段都适合建索引，也不是索引越多越好。重点给WHERE、JOIN、ORDER BY、GROUP BY中频繁出现的字段组合建索引。比如查询常按
status = 1 AND create_time > '2024-01-01'过滤，就建联合索引
(status, create_time)，顺序不能颠倒。单列索引对多条件查询效果有限，而冗余索引（如已有
(a,b)，又单独建
a）会拖慢写入且浪费空间。 用
EXPLAIN看
type是否为
ref或
range，避免
ALL注意最左前缀原则：查询只用到
b字段时，
(a,b)索引无法生效 字符串字段建索引要指定长度，如
INDEX idx_name (name(50))，避免索引过大
分页查询别用 OFFSET
当
LIMIT 1000000, 20这类深分页出现时，MySQL 仍需扫描前100万行才能跳过去，性能断崖式下跌。更优做法是用“游标分页”或“条件分页”： 记录上一页最后一条的主键值（如
id = 123456），下一页查
WHERE id > 123456 ORDER BY id LIMIT 20避免
SELECT *，只查必要字段，尤其避开大文本（
TEXT、
BLOB）列 如果必须用 offset，考虑在应用层缓存中间偏移位置，或改用 Elasticsearch 等专用检索引擎
拆分冷热数据，减少单表体量
历史数据（如一年前订单）查询频次低，却和热数据混在同一张表，拖慢整体查询。可按时间或业务维度归档：
用ALTER TABLE ... PARTITION BY RANGE (TO_DAYS(create_time))做分区，让查询自动裁剪分区 将旧数据迁出到历史表（如
order_2023），主表只保留近6个月数据 业务层路由：新订单写主表，查历史订单走归档表，配合视图或中间件统一接口
适当冗余和预计算
频繁聚合或关联查询慢，说明实时计算成本太高。可在写入时同步维护汇总结果：
用户订单总数不查SELECT COUNT(*) FROM orders WHERE uid=123，而是在用户表加
order_count字段，下单后
UPDATE users SET order_count = order_count + 1 WHERE id = 123统计报表类需求，用定时任务（如每小时）把结果写入宽表，查询直接读这张轻量表 关联多张大表的场景，考虑生成物化视图（MySQL 8.0+ 可用汇总表模拟）或使用 ClickHouse 做分析层
不复杂但容易忽略：定期用
SHOW INDEX FROM table_name和
information_schema.STATISTICS检查低效或未使用的索引，及时清理。优化不是一劳永逸，而是随数据增长和查询变化持续调整的过程。
