先确保查询结果准确再优化性能：按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
- 隐式类型转换：比如字段是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%的查询性能问题就解决了。
