MySQL 查询优化的核心是减少数据扫描量、加快定位速度、降低资源消耗，关键在于让数据库少干活、快响应，需结合索引优化、精简查询、合理建表及配置调优。
MySQL 查询优化的核心是减少数据扫描量、加快数据定位速度、降低服务器资源消耗。关键不在于写得多炫酷，而在于让数据库少干活、快响应。
用好索引，避免全表扫描
索引是查询提速最直接的手段。但不是建得越多越好，而是要匹配查询条件和排序 / 分组字段。
- WHERE 子句中的列优先建索引，尤其是高选择性（重复值少）的字段
- 联合索引注意最左前缀原则：red”>WHERE a=1 AND b=2 可用 (a,b) 索引，但 WHERE b=2 无法使用该索引
- 避免在索引列上做函数操作或 隐式类型转换，例如 WHERE YEAR(create_time)=2023 会让索引失效
- 用 EXPLAIN 查看执行计划，重点关注 type（最好为 ref 或 const）、key（是否命中索引）、rows（预估扫描行数）
精简查询逻辑，减少无效数据处理
很多慢查询源于“查得多、用得少”，比如返回全部字段、没加 LIMIT、多次嵌套子查询。
- 只 SELECT 需要的字段，别用 *；尤其避免在大表中 SELECT BLOB/TEXT 类型字段
- 分页查询慎用 LIMIT 10000,20，偏移量过大时仍需扫描前 10000 行；可改用游标方式（如记录上一页最大 ID）
- 能用 JOIN 就别用子查询，特别是相关子查询；JOIN 时确保关联字段类型一致且都有索引
- 避免在 WHERE 中使用 !=、NOT IN、OR（多个条件无索引时），考虑重写为 UNION 或 EXISTS
合理设计表结构与数据类型
表结构不合理，再好的 SQL 也难高效。从源头减少存储和计算负担。
- 字段尽量用最小够用的数据类型：比如状态用 TINYINT 而非 INT，手机号用 CHAR(11) 而非 VARCHAR(20)
- 避免 NULL 值过多，必要时用默认值替代；NULL 会增加索引和比较的复杂度
- 大文本、附件等分离到独立表或对象存储，主表只留引用 ID
- 单表字段不宜过多（建议≤50），超宽表考虑垂直拆分
关注执行环境与配置协同
SQL 写得再好，也可能被配置拖累。需结合 MySQL 运行参数与硬件资源综合调优。
- 检查 sort_buffer_size、join_buffer_size 是否过小，导致频繁磁盘排序或临时表
- 慢查询日志（slow_query_log）必须开启，阈值建议设为 1s，定期分析 mysqldumpslow 或 pt-query-digest
- 读多写少场景可考虑读写分离；热点 数据用缓存（如 Redis）前置，减轻 DB 压力
- 定期 ANALYZE TABLE 更新统计信息，帮助优化器生成更优执行计划
