MySQL查询是后端开发和数据分析里用到最频繁的操作没有之一。你写一千行业务代码可能里面八百行都在跟SELECT打交道。但现实是很多写了两年SQL的人碰到多表关联、去重、子查询更新还是会卡壳甚至跑出来的结果是错的都看不出来。这篇文章就把MySQL查询的核心语法完整拆一遍从执行顺序到WHERE、JOIN、GROUP BY、子查询、EXISTS再到实际业务里最常踩的坑一步步过适合刚入门想系统学SQL的初学者也适合写SQL全凭感觉、想回头补基础的同学。内容不绕弯子直接讲怎么用、为什么这么用、有哪些坑要躲。1. 先理清一条SELECT到底是怎么执行的很多人写SQL是“凭感觉写的”SELECT一句、FROM一句、WHERE再来一句能出结果就觉得完事了。但真正排查慢查询、优化SQL的时候必须知道一条查询在数据库内部是分几步走的不然你连调优的方向都找不到。1.1 书写顺序和执行顺序为什么完全不一样先看一个标准的查询语句SELECT c.name, COUNT(o.id) AS order_cnt FROM customer c LEFT JOIN order o ON c.id o.customer_id WHERE c.status 1 GROUP BY c.id HAVING COUNT(o.id) 1 ORDER BY order_cnt DESC LIMIT 10;这段SQL的书写顺序是SELECT → FROM → JOIN → WHERE → GROUP BY → HAVING → ORDER BY → LIMIT。但MySQL实际执行的时候顺序是反过来的大致是这样FROM先确定从哪张表取数如果是多表JOIN还要先做表连接生成一个临时结果集。WHERE在临时结果集上做行级过滤把不满足条件的行直接丢掉。GROUP BY按指定字段分组。HAVING对分组之后的结果再做过滤注意这一步能用的字段已经受限了。SELECT确定最终要输出的列可以在这里做表达式计算、函数处理。ORDER BY对输出的结果排序。LIMIT最后才做行数限制。这里最容易忽略的就是WHERE和HAVING的区别WHERE是在分组之前过滤原始行HAVING是在分组之后过滤聚合结果。我给你打个比方WHERE相当于你先筛掉坏苹果再装箱HAVING是装完箱之后只要超过5斤的箱子。这个顺序对写SQL的影响非常大。比如你想在WHERE里使用SELECT里起的别名MySQL很多版本直接报错因为执行到WHERE的时候SELECT还没执行别名根本不存在。我见过太多人写WHERE order_cnt 1然后一脸困惑地说“为什么报错”原因就是这个。1.2 理解执行顺序之后优化才有着力点以前有同事问我为什么一条SQL加了索引还是慢我说你先把执行顺序在脑子里过一遍如果WHERE里的条件字段没索引MySQL只能全表扫那加什么索引都白搭如果ORDER BY的字段没索引排序就要动用临时文件几百万行数据排序能不慢吗按执行顺序去分析慢查询思路会清晰很多能不能让FROM的表更小先过滤再关联比先关联再过滤快得多。WHERE里的字段有没有索引这是绝大多数慢查询的根源。GROUP BY的字段能不能走索引可以的话MySQL会避免创建临时表。排序字段能不能复用索引能的话就省掉了filesort。关于索引和SQL的配合后面实操部分我会再展开这里先把执行顺序这个地基打牢。1.3 FROM子句与表别名的潜规则有一个很隐蔽的问题多表JOIN的时候如果两张表有同名字段SELECT里必须用表别名.字段名来区分。很多人偷懒不写别名等表一多就彻底分不清了。我的习惯是每张表都给简短别名例如customer表叫corder表叫o这个习惯在稍微复杂一点的查询里能省掉大量改错成本。而且别名还能让SQL整体变短读起来也舒服。另外注意MySQL里如果你给表起了别名原始表名在同一个查询里就不能再用了。这个规则很多人不知道写了一半发现WHERE order.id 1报错改成WHERE o.id 1就好了。2. 核心语法逐个击破我见过太多人把SQL写成“能跑就行”但核心语法里每个关键字都有它存在的意义用对了是效率翻倍用错了是数据不准甚至直接把数据库拖垮。这一章节逐个讲透。2.1 WHERE过滤条件里的类型转换陷阱WHERE子句最基础但也是最容易埋雷的地方。最常见的问题就是字段类型不匹配导致索引失效。比如你的user表里phone字段是varchar类型但你在查询里写WHERE phone 13800138000这里没加引号MySQL会先把字段隐式转换成数字再去比较结果就是索引派不上用场全表扫描。-- 错误示范phone是varchar这样写会导致索引失效 SELECT * FROM user WHERE phone 13800138000; -- 正确写法字符串和字符串比较索引能正常使用 SELECT * FROM user WHERE phone 13800138000;这种问题在代码里非常难排查因为数据量小的时候感觉不到差异一旦表数据涨到几百万行查询直接慢到让你怀疑人生。排查方法也简单用EXPLAIN看一眼type列如果是ALL说明没走索引再检查一下是不是类型不匹配。另外WHERE里还有一个大坑对索引字段做函数运算。比如WHERE DATE(create_time) 2024-01-01看起来没毛病但它会让索引失效。正确做法是写成范围查询SELECT * FROM payment WHERE create_time 2024-01-01 00:00:00 AND create_time 2024-01-02 00:00:00;这样既满足业务语义又能让索引生效。我自己在项目里定过一条规矩凡是索引字段禁止包裹任何函数除非你明确知道自己在做什么。2.2 JOIN系列INNER JOIN、LEFT JOIN、RIGHT JOIN到底怎么选JOIN是SQL里最考验逻辑的部分。很多人分不清INNER JOIN和LEFT JOIN的区别我换个说法你就懂了INNER JOIN两边都匹配才保留等价于取交集。LEFT JOIN左表全保留右表没有匹配的补NULL。RIGHT JOIN右表全保留左表没有匹配的补NULL实际工作中用得很少因为把左右表换一下就是LEFT JOIN。先看一个经常出错的场景。你要查所有用户的订单数用户表在左订单表在右SELECT c.id, c.name, COUNT(o.id) AS order_cnt FROM customer c LEFT JOIN order o ON c.id o.customer_id GROUP BY c.id, c.name;这里有一个非常关键的点为什么左表是customerCOUNT的却是o.id因为如果某个用户没有订单LEFT JOIN之后右表字段全是NULLCOUNT(o.id)只统计非NULL值结果就是0。但如果你写成COUNT(*)会把那一行NULL也数进去结果变成1。这个坑我踩过一次统计报表里凭空多出几千个假订单排查了半天才发现是COUNT的用法问题。再来说说ON和WHERE的区别这个也经常把人绕晕。LEFT JOIN的时候ON条件在连接阶段就生效了WHERE条件在连接完成之后才生效。如果你想“左表全保留右表只取满足条件的记录”过滤条件必须写在ON后面如果写在WHERE后面会把左表中不满足条件的行也过滤掉效果就变成了INNER JOIN。-- 这样写保留所有用户只有已支付订单会关联上 SELECT c.id, c.name, o.amount FROM customer c LEFT JOIN order o ON o.customer_id c.id AND o.status paid; -- 这样写效果等于INNER JOIN没订单和没支付订单的用户全被过滤掉了 SELECT c.id, c.name, o.amount FROM customer c LEFT JOIN order o ON o.customer_id c.id WHERE o.status paid;这两种写法在业务含义上完全不同尤其是做报表统计的时候搞错了数据直接就偏了。我的建议是连表条件只放关联键行过滤条件统一放WHERE除非你有强烈需求要控制右表的匹配范围。2.3 聚合与GROUP BYCOUNT、DISTINCT的细节聚合函数是统计类的核心。先说COUNT(*)和COUNT(字段)的区别COUNT(*)统计所有行数不管字段是否为NULL。COUNT(字段)只统计该字段非NULL的行数。COUNT(DISTINCT 字段)统计该字段去重后的非NULL数量。看这个实际例子。你想统计用户数量但user表里有些行的nickname是NULLSELECT COUNT(*) AS total_cnt, COUNT(nickname) AS has_nickname_cnt, COUNT(DISTINCT uid) AS uid_cnt FROM user;第一列是总行数第二列只数有昵称的第三列才是真正有用的去重用户数。这种细节在报表场景里经常被忽略甩出来的数字对不上最后发现是聚合口径不同。再说GROUP BY。分组之后SELECT里能出现的列是有限制的一般只允许出现分组字段和聚合函数。MySQL的一个历史问题是默认开启了ONLY_FULL_GROUP_BY之后如果你SELECT一个既不在GROUP BY里、也没有被聚合函数包裹的字段直接报错。很多人第一次遇到这个报错就懵了其实就是SQL写得不严谨。解决办法是把该字段加到GROUP BY里或者用ANY_VALUE()包起来。但从规范角度我更建议你把需要的字段都写进GROUP BY别偷懒。还有一个实用技巧如果你需要去重查询优先考虑DISTINCT它简单直接。但DISTINCT和GROUP BY在去重逻辑上是一样的本质上都是分组。区别在于GROUP BY还能顺带做统计DISTINCT只能干巴巴地去掉重复行。比如你要查所有有订单的用户ID两个写法都可以SELECT DISTINCT customer_id FROM order; SELECT customer_id FROM order GROUP BY customer_id;数据量大的时候二者性能差别不大主要看后面是否还要继续聚合。要是还要统计订单数那直接用GROUP BY就好DISTINCT还得套一层子查询才能继续算。2.4 子查询与EXISTS什么时候用EXISTS更合理子查询分为无关子查询和关联子查询。无关子查询独立执行一次结果合并到外面关联子查询则对每一行都要执行一次所以逻辑要小心。常用的场景是“查询没有订单的用户”-- 用 NOT IN 的写法 SELECT id, name FROM customer WHERE id NOT IN ( SELECT customer_id FROM order ); -- 用 NOT EXISTS 的写法 SELECT c.id, c.name FROM customer c WHERE NOT EXISTS ( SELECT 1 FROM order o WHERE o.customer_id c.id );两条SQL都能查出同一个结果但逻辑上有细微差别。如果子查询结果里有NULLNOT IN的结果会变得不可靠因为SQL的三值逻辑里NOT IN (NULL, 1, 2)既不是真也不是假最后一条记录都查不出来。而NOT EXISTS是按行匹配不受NULL影响所以从健壮性角度我更喜欢EXISTS。从性能角度旧版本MySQL里EXISTS通常比IN快因为EXISTS是“只要找到一条就停止”。新版本MySQL对IN做了优化性能差距没那么大了但EXISTS的可读性和对NULL的免疫能力依然是一个优点。反过来如果子查询结果集很小用IN的写法更直观。还有一个实操点EXISTS的SELECT子句写SELECT 1还是SELECT *并不影响效率因为EXISTS只关心子查询是否返回了行不关心返回的具体值。写SELECT 1是行业习惯也方便别人一眼看出这是EXISTS用法。3. 从业务场景出发三个实战查询拆解语法讲再多不如直接来几个能落到业务里的完整案例。我选三个日常开发里出现频率非常高的场景每一个都是真实业务需求的抽象代码可以直接套用。3.1 场景一订单明细去重查询业务背景订单明细表里因为接口重复回调或者数据同步脚本跑重了同一个订单出现了多条重复记录。现在需要查出所有重复的订单号以及重复次数。表结构简化为CREATE TABLE order_item ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, product_name VARCHAR(64), created_at DATETIME );如果只是查“有哪些订单号是重复的”一句分组加HAVING就搞定SELECT order_no, COUNT(*) AS dup_cnt FROM order_item GROUP BY order_no HAVING COUNT(*) 1;注意这里HAVING放在GROUP BY后面作用是过滤分组结果。很多初学者会用WHERE COUNT(*) 1然后报错原因就是前面说的执行顺序WHERE在分组之前执行根本看不到聚合结果。如果你需要把重复的记录完整列出来用一张临时表或者子查询SELECT * FROM order_item WHERE order_no IN ( SELECT order_no FROM order_item GROUP BY order_no HAVING COUNT(*) 1 ) ORDER BY order_no;这个查询在生产环境的数据修复里很常见查出来之后导出、人工核对、再清理冗余数据一步一步来。3.2 场景二查询每个分类下的最新一条记录这个需求几乎每个项目都会遇到商品表里同一个分类有很多商品要取出每个分类下最新上架的那一件。CREATE TABLE product ( id INT PRIMARY KEY AUTO_INCREMENT, category_id INT NOT NULL, title VARCHAR(128), created_at DATETIME );经典写法是关联子查询先查出每个分类的最大时间再连回产品表取完整记录SELECT p.* FROM product p INNER JOIN ( SELECT category_id, MAX(created_at) AS max_time FROM product GROUP BY category_id ) t ON p.category_id t.category_id AND p.created_at t.max_time;这个写法的思路是先缩小“候选集”再关联回原表取明细效率和数据准确性都可控。但要注意如果同一个分类下有两个商品时间完全一样查出来会是两行。如果业务上要求绝对唯一比如每个分类只保留一个那还需要再加一个排序字段或者用窗口函数ROW_NUMBERSELECT id, category_id, title FROM ( SELECT id, category_id, title, ROW_NUMBER() OVER ( PARTITION BY category_id ORDER BY created_at DESC, id DESC ) AS rn FROM product ) t WHERE rn 1;MySQL 8.0以上版本支持窗口函数这个写法在“每组取前N条”的场景里非常方便。如果你的库是5.7那就用上面的关联子查询方案效果也不差。3.3 场景三用更新子查询批量修数据热搜词里有“mysql中更新子查询”这确实是实际工作中绕不开的操作。典型需求是把用户表里的VIP等级统一同步成订单表里最近一笔订单的等级。简单说就是UPDATE语句里套SELECT。直接写子查询可能踩两个坑一是子查询返回了多行二是更新同一张表的时报错。先看一个“在UPDATE里直接查同表”的经典错误-- 这样会报错You cant specify target table for update in FROM clause UPDATE user u SET u.vip_level ( SELECT MAX(level) FROM user_order_log l WHERE l.user_id u.id );如果user_order_log和user是同一张表MySQL会拒绝执行这是保护机制防止你在迭代更新过程中读到不一致的数据。解决方法是包一层临时派生表UPDATE user u INNER JOIN ( SELECT user_id, MAX(level) AS max_level FROM user_order_log GROUP BY user_id ) t ON u.id t.user_id SET u.vip_level t.max_level;这个用JOIN代替子查询的做法也叫“关联更新”在MySQL里是标准方案比逐行UPDATE要快得多而且代码意图清晰。顺便提醒一下做批量更新前一定先备份目标表哪怕只是复制一张临时表出问题的时候你会感谢这个习惯。4. 高频问题与排查技巧实录这一章节我不讲概念全部是实际排障过程中总结出来的高频问题每一条背后都有真实案例撑着。你可以直接把这一节当速查手册用。4.1 问题一查询结果突然出现重复行这个问题的排查思路先不要急着怪数据库大部分原因是SQL逻辑本身写了笛卡尔积或者JOIN条件漏了关联字段。举个例子你查订单和订单明细SELECT o.order_no, oi.product_name FROM order o LEFT JOIN order_item oi ON o.id oi.order_id; -- 一行订单对应多行明细结果当然会重复这不是“突然”重复而是一对多关系天然导致的。如果你只想要订单号列表却去关联明细表重复是必然的。解决办法是用DISTINCT去重或者先聚合明细表的数量再关联。还有一类重复是JOIN条件写错了比如只关联了时间字段忘了关联用户ID导致两个用户的数据互相匹配这种重复最隐蔽因为看起来数据好像“差不多”。排查方法就是把所有关联条件列出来看一遍确保能唯一定位到目标记录。4.2 问题二NULL参与运算导致结果全部归零MySQL里NULL和任何值做算术运算结果都是NULL。比如你统计订单金额的时候写SELECT user_id, SUM(amount coupon_amount) AS total_pay FROM order GROUP BY user_id;如果某个订单的coupon_amount是NULL那amount coupon_amount整个变成NULLSUM一累加这个订单的金额直接被吃掉了。正确写法是先处理NULLSELECT user_id, SUM(COALESCE(amount, 0) COALESCE(coupon_amount, 0)) AS total_pay FROM order GROUP BY user_id;COALESCE函数按顺序返回第一个非NULL值这是处理NULL最常用的函数。类似的场景还有用IFNULL(amount, 0)效果差不多。另外还有个查询陷阱判断字段是否为NULL要用IS NULL或者IS NOT NULL不能用 NULL。 NULL的结果永远是NULL连WHERE条件都算不上“真”所以查不到任何数据。这种问题在代码里非常难以察觉因为SQL不报错就是结果为空。4.3 问题三分页查询越翻越慢分页是每个后端都会写的功能LIMIT 10000, 20这种写法在数据量小的时候没感觉到了百万级就开始卡。原因很简单MySQL要先把前10000行查出来丢掉再返回后面20行前面的行数越多浪费越大。优化方案可以这样SELECT * FROM order WHERE id 10000 ORDER BY id LIMIT 20;这个写法的核心是记住上一页最后一条记录的ID然后往后翻。前提是排序字段必须是连续的、唯一的比如自增主键。如果业务排序不是按ID那可以先子查询拿到起始ID再继续翻页比如SELECT * FROM order WHERE id ( SELECT id FROM order ORDER BY id LIMIT 10000, 1 ) ORDER BY id LIMIT 20;这种方案在深分页场景里比直接LIMIT快非常多而且SQL改动不大适合快速上线。注意前提表的主键必须连续递增。 如果主键有删除导致的空洞用ID分页会跳行这时候就得老老实实用LIMIT或者改用游标分页配合业务排序键来做。4.4 问题四如何用EXPLAIN给慢查询定位EXPLAIN是MySQL排查SQL性能问题最重要的工具没有之一。用法很简单在你要分析的SQL前面加上EXPLAIN关键字EXPLAIN SELECT * FROM order WHERE user_id 123;输出结果里重点看这几列列名重点关注type从好到差依次是system const eq_ref ref range index ALL看到ALL就要高度警惕key实际用到的索引NULL表示没走索引rows预估扫描行数数值越大越危险Extra出现Using filesort、Using temporary需要重点优化我举个例子一条查询的EXPLAIN结果里type是ALLrows是500万。这基本可以断定它在全表扫描。这时候看WHERE条件里有没有可用的索引没有就建索引有但没走就检查字段类型匹配、函数包裹、隐式转换这几个老问题。之前我处理过一个线上慢查询页面打开要8秒EXPLAIN一看问题出在ORDER BY字段没索引临时文件排序花了5秒多。加完索引之后直接降到100毫秒这就是排查工具的价值。下面简单整理了一个速查表方便你日常对照问题现象大概率原因排查思路结果集出现重复行JOIN导致一对多或关联条件缺失检查JOIN条件必要时DISTINCT聚合数字不对NULL参与运算或COUNT用错换成COALESCE处理NULL查询很慢WHERE字段无索引或索引失效EXPLAIN看type和key分页越深越慢LIMIT offset过大用ID游标翻页更新同表报错MySQL限制UPDATE里直接查同表包一层派生表或用JOIN UPDATE字段类型不一致隐式转换导致索引失效统一字段类型或补引号最后分享几个写SQL的小习惯写SQL不要把重点放在“能不能跑出结果”要放在“这个结果是不是业务真正想要的”。我在实际开发里吃过太多次亏结果数字对不上最后发现不是SQL语法问题而是语义理解错了。所以现在每写一条稍微复杂点的SQL我都会先在心里过一遍执行顺序再对照业务需求确认统计口径。另一个习惯是把常用查询模板化。比如“每个分类取最新一条”“统计每天的用户新增量”“关联表后做分组汇总”这类SQL结构其实高度相似沉淀成模板之后新需求来了改改表和字段就行出错概率低很多。还有一个建议是多用EXPLAIN。哪怕只是给自己写的SQL做一个健康检查花不了几秒钟但能提前发现索引问题。数据库慢查询一旦上了生产再处理代价就大了。先分析、再优化、最后压测这套流程养成习惯之后写SQL的效率会高出一大截。