先确保查询结果准确再优化性能：按 SELECT→FROM→WHERE→GROUP BY→HAVING→ORDER BY→LIMIT 顺序编写；避免 SELECT *、函数包裹字段、隐式类型转换、N+ 1 子查询；合理建索引并用 EXPLAIN 验证。
SQL 基础查询写得对，后面优化才有意义。核心是先让结果准确，再让速度变快——别一上来就加索引、改执行计划，数据都查错了，再快也没用。
基础查询怎么写才靠谱
一个标准的 SELECT 语句，按逻辑顺序写清楚：SELECT → FROM → WHERE → GROUP BY → HAVING → ORDER BY → LIMIT。虽然 SQL 执行时顺序不同（比如 WHERE 在 GROUP BY 之前生效），但人写的时候按这个顺序，不容易漏条件、错聚合。
- 只查需要的字段，别无脑SELECT *——尤其表有大文本或 JSON 字段时，IO 和网络开销直线上升
- WHERE 条件优先用等值查询（=），再考虑范围（>、BETWEEN），模糊匹配（LIKE ‘%abc’）尽量避免前导通配符
- 多表关联用 INNER JOIN 明确语义，别靠逗号拼 FROM；ON 条件写在 JOIN 后，过滤条件留在 WHERE 里，别混着放
哪些地方最容易拖慢查询
不是数据量大才慢，很多“小表慢查”是因为写了反模式操作。
- 函数包裹字段：比如WHERE YEAR(create_time) = 2024，会让索引失效；改成create_time >= ‘2024-01-01′ AND create_time 2025-01-01’
- 隐式类型转换：比如字段是 VARCHAR，却写WHERE user_id = 123（数字），MySQL 可能放弃索引；统一类型，该加引号就加
- SELECT 中用子查询或计算列：如SELECT name, (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) FROM users u，会变成 N + 1 查询；优先考虑 JOIN 或窗口函数替代
索引不是万能的，但没它是真慢
索引要建在“常被查、选择性高、参与排序 / 分组”的列上。一句话判断要不要建：这列是否经常出现在 WHERE、ORDER BY、GROUP BY、JOIN ON 里？
- 单列索引够用就不建联合索引；联合索引注意 最左前缀原则 ，比如(a,b,c) 能加速 WHERE a=1 或WHERE a=1 AND b>2，但对 WHERE b=2 无效
- 区分度低的字段（如性别、状态位）单独建索引意义不大；可考虑和高频过滤字段组合成联合索引
- 用 EXPLAIN 看执行计划：重点关注type（最好到 ref/const）、key（是否命中索引）、rows（扫描行数越少越好）、Extra（警惕 Using filesort、Using temporary）
小技巧让日常查询更稳更快
不靠改配置、不碰执行计划，也能立竿见影。
- 加 LIMIT 别手滑写成LIMIT 10000,20——偏移量太大时，MySQL 仍要扫前 10000 行；改用游标分页：WHERE id > last_seen_id ORDER BY id LIMIT 20
- 统计总数慎用 COUNT(*)全表扫，如果只是“是否有数据”，用 SELECT 1 FROM table WHERE … LIMIT 1 更快
- 开发环境 养成习惯：每写一条带 WHERE 的查询，顺手 EXPLAIN 一下；上线前跑一遍慢日志分析（如 MySQL 的 slow_query_log）
基本上就这些。SQL 优化不是玄学，是观察 + 验证 + 微调的过程。把基础写对，把常见坑避开，80% 的查询性能问题就解决了。
