SQL 查询变慢主因是写法、表结构与执行路径不合理；索引需匹配 WHERE 等实际使用条件，复合索引字段顺序要与查询条件一致，避免对索引字段用函数。
SQL大数据 查询变慢，核心问题往往不在数据量本身，而在查询写法、表结构和执行路径是否合理。优化不是堆硬件，而是让数据库“少走弯路、快找数据”。
索引不是越多越好，而是要匹配查询条件
索引本质是快速定位数据的“目录”。但只有被 WHERE、JOIN、ORDER BY、GROUP BY 实际用上的列，才值得建索引。
- 复合索引要注意字段顺序：比如 WHERE status = ? AND create_time > ?，适合建(status, create_time) 索引；反过来就可能失效
- 避免对索引字段做函数操作：WHERE YEAR(create_time) = 2024会让索引失效，改用create_time >= ‘2024-01-01′ AND create_time 2025-01-01’
- 区分“高基数”和“低基数”字段：性别、状态这类取值少的字段，单独建索引效果差，更适合配合其他字段组成复合索引
减少扫描数据量，从源头控制返回结果
数据库最耗时的操作之一是读取大量无关行。优化重点是“别查不该查的”。
- 明确指定字段，不用SELECT *：尤其当表有大文本、JSON 或 BLOB 字段时，全字段读取会大幅增加 IO 和网络传输
- 尽早过滤：把 WHERE 条件尽量下推到子查询或 JOIN 前；用 LIMIT 分页时注意深分页问题（如 OFFSET 1000000），可改用“游标分页”（基于上一页最大 ID 继续查）
- 避免 隐式类型转换：比如WHERE user_id = ‘123’（user_id 是 INT），会导致索引失效，应保持类型一致
JOIN 和子查询要谨慎，优先考虑逻辑拆解
多表关联容易引发笛卡尔积或临时表膨胀，尤其是大表之间没走索引 JOIN 时，性能断崖式下跌。
- 确认 JOIN 字段都有索引，且类型、字符集完全一致（比如 utf8mb4 vs utf8 可能不走索引）
- 大表 JOIN 小表，确保小表在前（部分引擎如 MySQL 5.7+ 优化器会自动调整，但显式控制更稳妥）
- 用 EXISTS 替代 IN 子查询处理存在性判断；用 LEFT JOIN + IS NULL 替代 NOT IN（后者对 NULL 敏感，易出错且难优化）
- 超复杂查询可拆成中间临时表（如 CREATE TEMPORARY TABLE）或物化 CTE（PostgreSQL/Oracle 支持），避免重复计算
善用执行计划，别靠猜
EXPLAIN（或 EXPLAIN ANALYZE）是诊断查询性能的“听诊器”，它告诉你数据库实际怎么执行的。
- 重点关注type（是否用到索引：ALL 最差，range/ ref/ eq_ref 较好）、rows（预估扫描行数）、Extra（是否 Using filesort、Using temporary——意味着排序 / 分组用了临时表）
- 对比加索引前后的执行计划变化，验证优化是否真正生效
- 生产环境慎用 SELECT FOR UPDATE 或长事务，它们会阻塞并影响并发查询性能
基本上就这些。SQL 优化不是一招鲜，而是一套组合动作：建对索引、写对语句、看清执行路径、再结合业务场景做取舍。不复杂但容易忽略。
