sql查询慢主因是写法或设计不当，优化需观察执行计划、合理建索引、精简查询逻辑、定期更新统计信息，并持续迭代。
SQL查询慢，通常不是数据库不行，而是写法或设计没跟上需求。优化不靠猜，靠观察、分析和针对性调整。核心思路是：减少扫描数据量、加快定位速度、避免运行时开销。
看懂执行计划，找到性能瓶颈
执行计划（Execution Plan）是数据库实际执行SQL的步骤图，是优化的第一手依据。在mysql中用EXPLaiN，postgresql用EXPLAIN ANALYZE，SQL Server用SET STATISTICS xml ON。
- 重点关注type（访问类型）：从const、ref到range、ALL，越靠后扫描越多
- 留意rows字段：预估扫描行数，远大于返回结果数就该警惕
- 检查Extra列：出现using filesort或Using temporary往往意味着排序/分组没走索引
善用索引，但别乱建
索引不是越多越好，而是要匹配查询模式。高频WHERE条件、JOIN字段、ORDER BY和GROUP BY字段是建索引的优先候选。
- 复合索引注意最左前缀原则：比如INDEX (a, b, c)能加速WHERE a=1、WHERE a=1 AND b=2，但对WHERE b=2无效
- 避免在低区分度列（如性别、状态码）单独建索引，效果微弱还拖慢写入
- 覆盖索引可避免回表：select只查索引字段（如INDEX (user_id, create_time)，查询SELECT user_id, create_time就不用再查主键表）
精简查询逻辑，少做无用功
很多慢查询源于“查得多、用得少”，或在数据库里做了本该由应用处理的事。
- 用SELECT 具体字段代替SELECT *，尤其表有大文本或jsON字段时
- 分页慎用LIMIT offset, size：offset越大越慢；深分页建议用游标方式（如WHERE id > last_seen_id ORDER BY id LIMIT 20）
- 避免在WHERE中对字段做函数操作：WHERE YEAR(create_time) = 2024会跳过索引；改成WHERE create_time BETWEEN ‘2024-01-01’ AND ‘2024-12-31’
定期清理与统计更新
数据库依赖统计信息做执行计划选择。表数据大幅变动后，旧统计可能让优化器误判。
- MySQL：执行ANALYZE table table_name更新统计
- PostgreSQL：运行VACUUM ANALYZE table_name
- 注意监控碎片率和过期数据，及时归档或删除无用历史记录
基本上就这些。sql优化不是一劳永逸，而是随着数据增长和业务变化持续迭代的过程。从一条慢查询开始，看执行计划、调索引、改写法，见效快、成本低。