聊到MySQL 常用关键字，很多人第一反应是去翻官方文档里那份很长的关键字列表，然后背下来。但说句实在话，真正在写 SQL 时高频出现的核心关键字就那二三十个，而且很多人的问题并不在于“不知道”，而在于“不知道这些关键字在什么位置、什么场景下才该出场”。我这些年排查过不少慢 SQL 和逻辑错误的 SQL，发现很大一部分原因，是开发者把 WHERE、GROUP BY、HAVING、JOIN 这些关键字的位置和分工搞混了。所以这篇就换个思路，不按字典顺序罗列，而是按“一条 SQL 从取数到返回结果、从查询到变更、从建表到跑事务”的真实链路，把那些最常用的关键字逐个拆开，讲清楚它们到底在干什么、有什么边界、踩过哪些坑。适合刚接触 MySQL 的同学做体系化梳理，也适合写过一段时间但总在细节上出问题的开发者对照自查。
1. 查询关键字的执行顺序：SELECT、FROM、WHERE、GROUP BY、HAVING、ORDER BY、LIMIT 谁先谁后
1.1 我常用的“执行顺序速查表”
刚开始学 MySQL 的时候，我也以为一条 SQL 是从 SELECT 开始读的，毕竟它写在最前面。后来踩了好几次“字段不存在”的坑，才真正意识到：SQL 的书写顺序和执行顺序是两回事。MySQL 拿到一条查询语句后，实际处理顺序大致是：
- FROM：确定从哪张表取数据，包含 JOIN 的表也会在这一步做关联
- WHERE：对 FROM 阶段得到的结果做逐行过滤
- GROUP BY：按指定列分组
- HAVING：对分组之后的结果做过滤
- SELECT：计算并选取需要的列、表达式、聚合结果
- ORDER BY：对结果排序
- LIMIT：限制返回的行数
这张顺序表是所有查询类关键字的“总纲”。我一般会在脑子里过一遍这条链路，再去组织 SQL。比如写 WHERE 的时候心里清楚，这一步是在“分组之前”过滤，所以不能用聚合函数；写 HAVING 的时候清楚，这一步是“分组之后”过滤，可以放心写 SUM()、COUNT() 这些聚合结果。顺序对了，很多莫名其妙报错的原因就自然浮现出来了。
1.2 顺序对实际写的 SQL 有什么影响
最直接的影响是别名问题。举个例子，有人喜欢写：
SELECT order_date AS d, SUM(amount) AS total FROM orders WHERE d > '2025-01-01' GROUP BY d;这条在 MySQL 里很可能会报错“Unknown column 'd' in 'where clause'”，原因就是 WHERE 在 SELECT 之前执行，压根还没生成 d 这个别名。但同样的 SQL，把 d 挪到 ORDER BY 里用就合法，因为 ORDER BY 在 SELECT 之后执行，MySQL 允许在 ORDER BY 阶段引用 SELECT 别名。这个差异不是 MySQL 故意刁难，而是执行顺序的必然结果。
同样，LIMIT 在最后执行，很多人会以为 LIMIT 能提前减少 WHERE 的过滤量，不能。你可以把 LIMIT 理解为“结果集已经全部算好之后，只截取其中一段送给你”。这也是为什么几乎所有带 LIMIT 的分页查询，在数据量大了之后都会变慢，因为前面该算的聚合、排序一步都没少。
2. WHERE、GROUP BY、HAVING：判断条件写在哪一层，结果完全不同
2.1 WHERE 和 HAVING 的本质区别
很多初学者最难绕过去的弯，就是 WHERE 和 HAVING 都表示“过滤”，到底有什么区别。我的理解方式很简单：WHERE 是分组前过滤，HAVING 是分组后过滤。WHERE 过滤的是 FROM 阶段出来的“原始行”，HAVING 过滤的是 GROUP BY 分组后生成的“分组行”。
举个实际场景。订单表 orders 里有 user_id、amount、status 三个字段。我想统计“已支付用户的订单总额大于 1000 的用户”。如果一开始就用 HAVING 去过滤 status，会先把所有订单分好组、算好总额，最后才发现有些还没支付的订单混在里面，但为时已晚。正确写法是：
SELECT user_id, SUM(amount) AS total_amount FROM orders WHERE status = 'paid' GROUP BY user_id HAVING total_amount > 1000;区别很明显：WHERE 先把“未支付”的行剔掉，参与分组的行变少，聚合计算更快；HAVING 则是先把所有行分组算完，再丢掉总额不满意的组。能写 WHERE 的条件，永远优先写 WHERE，这不仅是语义正确的问题，也是性能问题。
2.2 GROUP BY 与 ONLY_FULL_GROUP_BY 的恩怨
MySQL 5.7 之后默认开启了 ONLY_FULL_GROUP_BY 模式。这个模式下的规则是：SELECT 后面出现的列，要么是 GROUP BY 里写过的列，要么是被聚合函数包裹的列。比如：
SELECT user_id, order_date, SUM(amount) FROM orders GROUP BY user_id;在严格模式下直接报错，因为 order_date 既没出现在 GROUP BY 里，也没被 SUM()、MAX() 这类函数包住。这个报错不是 MySQL 抽风，而是防止你拿一个不确定的值当真。每个分组里可能有十条订单，order_date 到底取哪一条？MySQL 没有义务替你做这个决定。
实际开发里我见过不少人为了“消掉报错”，随手把 order_date 也塞进 GROUP BY，或者用 MIN(order_date)、ANY_VALUE(order_date) 去绕。这两种做法本质不同：塞进 GROUP BY 意味着“每个用户按不同日期再分组”，语义变化了；用 ANY_VALUE 则是明确告诉 MySQL“这个分组内任意取一个值就行”。用哪个，取决于业务逻辑，不是哪个能跑就选哪个。
2.3 一次真实的分组排查过程
之前帮某团队看一条统计 SQL，需求是统计每个品类下价格最高的商品。最初的写法是：
SELECT category_id, MAX(price), product_name FROM products GROUP BY category_id;这条在早期 MySQL 版本能跑，但 product_name 取的是分组内随机一条，经常和 MAX(price) 对不上。我排查的时候先确认了版本和 sql_mode，替换成用子查询关联的方式，先查出每个品类最高价，再回表找对应的商品名：
SELECT p.category_id, p.price, p.product_name FROM products p JOIN ( SELECT category_id, MAX(price) AS max_price FROM products GROUP BY category_id ) t ON p.category_id = t.category_id AND p.price = t.max_price;虽然多了一层子查询，但语义完全正确，也不会出现“写出来跑得通、结果却是错”这种更危险的情况。要记住：能跑和跑对是两回事。
3. JOIN 与子查询关键字：INNER/LEFT/RIGHT/CROSS 和 EXISTS/IN 的取舍
3.1 JOIN 类型速览
JOIN 是写多表查询时绕不开的关键字，但我发现不少人只用 LEFT JOIN，其他类型一概不问。这里快速过一遍它们的区别：
| 关键字写法 | 含义 | 典型场景 |
|---|---|---|
| INNER JOIN | 只返回两边匹配上的行 | 取订单和用户都存在的记录 |
| LEFT JOIN | 返回左表所有行，右表没匹配到就补 NULL | 以左表为主体，补右表信息 |
| RIGHT JOIN | 返回右表所有行，左表没匹配到就补 NULL | 和 LEFT JOIN 方向相反 |
| CROSS JOIN | 笛卡尔积，两边所有行两两组合 | 极少用，除非刻意生成组合 |
实际项目里我基本只用 INNER JOIN 和 LEFT JOIN。RIGHT JOIN 可以用交换表顺序的方式改写成 LEFT JOIN，可读性更好。CROSS JOIN 基本只在连数字表生成序列时用，平时写业务 SQL 出现 CROSS JOIN，大概率是漏写了 ON。
3.2 ON 和 WHERE 的区别：LEFT JOIN 里最容易踩的坑
这个坑我几乎每年都会遇到。LEFT JOIN 时把过滤条件写在 ON 后面和写在 WHERE 后面，结果完全不同。区别在于：ON 决定左表行是否匹配右表，WHERE 决定最终结果里哪些行留下。
写一个反例。想查所有用户及其订单，只要“未支付”的订单。有人这么写：
SELECT u.user_id, o.order_id FROM users u LEFT JOIN orders o ON u.user_id = o.user_id WHERE o.status = 'unpaid';这条 SQL 的结果是：只有那些“存在未支付订单”的用户才会出现在结果里，没下过单的用户被过滤掉了。问题在哪？LEFT JOIN 本来要保留所有用户，但 WHERE 一压过来，所有右表为 NULL 的行直接出局，LEFT JOIN 就“退化”成了 INNER JOIN。正确的做法是把条件放到 ON 后面：
SELECT u.user_id, o.order_id FROM users u LEFT JOIN orders o ON u.user_id = o.user_id AND o.status = 'unpaid';这样才能得到“所有用户，以及他们的未支付订单（没有则为 NULL）”。判断要不要把条件挪进 ON，核心就一句话：这个条件是“决定要不要关联右表”，还是“决定最后展示哪些行”？前者放 ON，后者放 WHERE。
3.3 EXISTS 和 IN 的使用边界
EXISTS 和 IN 都能做子查询判断，性能差异要看子查询的数据量和关联方式。我自己的经验法则：
- 子查询结果集很小，比如几百条内，用 IN 顺手，可读性好；
- 子查询表很大，且外层表数据相对少，用 EXISTS 通常更快。EXISTS 是“外层行有匹配就停”的短路判断，不需要把子查询全部结果物化；
- 如果涉及 NULL 值判断，要注意 IN 遇到 NULL 时可能产生“非预期不匹配”的情况，而 EXISTS 没这个问题。
举个例子，查“有订单的用户”：
SELECT u.user_id, u.name FROM users u WHERE EXISTS ( SELECT 1 FROM orders o WHERE o.user_id = u.user_id );注意子查询里写 SELECT 1 而不是 SELECT *，纯粹是为了“判断是否存在”，没人在意它返回什么列。这是一种约定俗成的优化写法，MySQL 同样也会做优化，写成 SELECT * 也不会有明显差异，但 SELECT 1 在语义上更明确：我不关心列内容，只关心有没有这条记录。
4. 数据变更关键字：INSERT、UPDATE、DELETE 的扩展用法与安全习惯
4.1 INSERT 的几种写法
INSERT 不止一种形态。最常规的是INSERT INTO table (col1, col2) VALUES (val1, val2)，但实际开发里更常用的是批量写法：
INSERT INTO orders (user_id, amount, status) VALUES (1, 99.00, 'paid'), (2, 128.00, 'pending'), (3, 45.50, 'paid');一次插入多行，比循环单条 INSERT 快一个量级，这是我在性能优化里最先动手的位置之一。如果某天线上数据导入特别慢，先别急着调 MySQL 参数，看看是不是逐条 INSERT 提交，改成批量后通常立竿见影。
还有一个常用变体，INSERT INTO ... ON DUPLICATE KEY UPDATE。这个语法的意思是：插入时如果唯一键或主键冲突，就改为执行 UPDATE。比如做每日汇总表，某用户当天已有记录就累加金额，没有就插入。写成：
INSERT INTO user_daily_stats (user_id, stat_date, total_amount) VALUES (1, '2025-06-01', 199.00) ON DUPLICATE KEY UPDATE total_amount = total_amount + 199.00;注意：ON DUPLICATE KEY 里的 UPDATE 不写表名，直接写列名赋值。这个细节我见过不少人写错，多了表名直接语法报错。
4.2 UPDATE 和 DELETE 必备的自我防护习惯
关于 UPDATE 和 DELETE，我最想强调的不是语法，而是习惯。MySQL 默认情况下不带 WHERE 的 UPDATE 会更新所有行，不带 WHERE 的 DELETE 会清空全表。任何一次手滑，都是事故级的。我的个人习惯是：
- 先写条件，再写语句。写
UPDATE table SET ... WHERE ...时，先把 WHERE 写好，再回来补 SET； - 变更前先跑一遍相同 WHERE 的 SELECT，确认影响范围；
- 生产环境操作尽量用事务包起来，出问题立即 ROLLBACK；
- DELETE 语句我几乎不用不带条件的写法，即便要清空表，也更倾向用 TRUNCATE TABLE，因为它不做逐行删除，速度极快，但注意它不会触发 DELETE 触发器，而且要谨慎确认。
4.3 变更语句里容易忽略的细节
UPDATE 语句里也有 JOIN 和多表更新的用法。比如要把所有“待支付超过 30 天”的订单标记为超时，可以写：
UPDATE orders o SET o.status = 'timeout' WHERE o.status = 'pending' AND o.created_at < NOW() - INTERVAL 30 DAY;这里用了 NOW() 和 INTERVAL，没有引入子查询，就是基于单表条件过滤，简单直接。如果涉及多表关联更新，比如用 A 表的字段更新 B 表，MySQL 支持 UPDATE 后面跟 JOIN 的写法，但要注意这类 SQL 可读性和维护性差，我会优先拆成“先查出目标列表，再按主键批量更新”两段式，宁可多两条语句，也不用一条看起来很聪明但很难排查问题的 SQL。
删除的时候同样，如果数据量大，分批 DELETE 比一次删干净更稳妥。一次删除五十万行，会产生巨大的 binlog 和锁等待；改成每次删除五千行、循环二三十次，反而总耗时更可控，对线上的影响也小得多。
5. 事务关键字组合拳：BEGIN、COMMIT、ROLLBACK、SAVEPOINT 的实操
5.1 一个事务的完整生命周期
事务是 MySQL 里一组 SQL 的“打包执行”。起点是 BEGIN 或 START TRANSACTION，终点是 COMMIT 或 ROLLBACK。我推荐 START TRANSACTION 而不是 BEGIN，因为前者更语义清晰，也方便后续扩展隔离级别。
一个典型的转账场景，最简单的事务长这样：
START TRANSACTION; UPDATE accounts SET balance = balance - 100 WHERE user_id = 1; UPDATE accounts SET balance = balance + 100 WHERE user_id = 2; COMMIT;整个过程里任何一个 UPDATE 出错，都可以 ROLLBACK 让两条语句都不生效。这里有个容易忽略的细节：默认情况下，MySQL 的每一条 DML 语句都是自动提交的，也就是你执行一条 UPDATE，没有显式事务它也会立刻落库。只有显式写了 START TRANSACTION，自动提交才会被暂时关掉，直到 COMMIT 或 ROLLBACK。所以如果你改了数据发现没真正生效，先想清楚是不是事务没有提交。
5.2 SAVEPOINT 的嵌套回滚
事务内部还能设置保存点，用 SAVEPOINT 关键字。回滚时可以只回滚到某个保存点，而不是整个事务。这个特性在处理“长事务里的局部失败”时很有用。
举个例子：
START TRANSACTION; UPDATE account SET balance = balance - 100 WHERE user_id = 1; SAVEPOINT before_point; UPDATE account SET balance = balance + 100 WHERE user_id = 2; -- 这里发现第二条写错了，只需要回滚到保存点 ROLLBACK TO SAVEPOINT before_point; -- 然后可以重新执行正确的第二条，再整体提交 COMMIT;我用 SAVEPOINT 的场景不算多，但一旦碰上“一个事务里前半段已经成功、后半段失败又不想全部作废”的情况，它比拆成两个事务优雅太多。记住一个点：ROLLBACK TO SAVEPOINT 并不会结束事务，事务还开着，只是把状态回退到了保存点那个时刻。
5.3 事务与隔离级别的配合
事务关键字里不直接包含隔离级别，但它们配合密切。常用的隔离级别关键字是 SET TRANSACTION ISOLATION LEVEL，常见值有 READ COMMITTED 和 REPEATABLE READ。MySQL 默认是 REPEATABLE READ，这也意味着同一个事务里，同样的 SELECT 两次结果是一致的，做到“可重复读”。
我的经验是：业务系统如果没有特殊需求，就保持默认级别，别随意改动。记得有一次某团队说 MySQL 出现“数据重复”，排查半天发现是有人把隔离级别改成了 READ UNCOMMITTED，导致还没提交的事务数据被另一个会话读到了。隔离级别这种东西，改起来只写一行 SQL，但影响的是全局并发行为，线上动它之前一定想清楚。
6. 建表与改表关键字：约束、索引及 ALTER TABLE 的常见坑
6.1 常用约束：PRIMARY KEY、UNIQUE、NOT NULL、DEFAULT
建表时的关键字不只是字段类型，约束是保证数据质量的第一道闸门。我最常用的几个：
- PRIMARY KEY：主键约束，一张表有且仅有一个，常用自增整数或唯一业务号；
- UNIQUE：唯一键，保证一个或一组列的值不重复；
- NOT NULL：非空约束，这个约束看起来简单，但对查询性能有正面影响，因为有了它，MySQL 能少做不少 NULL 判断；
- DEFAULT：给字段一个默认值，是避免写 INSERT 时漏字段的兜底措施。
举个例子：
CREATE TABLE users ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, email VARCHAR(255) NOT NULL, nickname VARCHAR(32) DEFAULT '新用户', PRIMARY KEY (id), UNIQUE KEY uk_email (email) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这里 CHARSET 我直接写 utf8mb4，而不是老的 utf8。当年用 utf8 存 emoji 会报错甚至存成问号的坑，想必很多人还记得。从建表之初就把字符集定对，是省后面大量迁移工作的事。
6.2 ALTER TABLE 的 MODIFY 还是 CHANGE ？
改表结构时，MODIFY 和 CHANGE 是高频关键字，但很多新手不知道它们的区别。简单说：
- MODIFY：修改字段的类型、默认值、注释等属性，不改字段名；
- CHANGE：可以改字段名，也可以顺带改属性。
比如给 nickname 字段加默认值，用 MODIFY：
ALTER TABLE users MODIFY nickname VARCHAR(32) DEFAULT '新用户';如果要同时把 nickname 改名成 display_name，用 CHANGE：
ALTER TABLE users CHANGE nickname display_name VARCHAR(32) DEFAULT '新用户';注意 CHANGE 需要把新字段的完整定义重写一遍，漏了类型就会报错。我的习惯是：只改属性用 MODIFY，必须改名才用 CHANGE，不要图省事混用。
6.3 索引关键字：INDEX、UNIQUE KEY、FULLTEXT 与 SPATIAL
索引关键字里，普通索引写 INDEX，唯一索引写 UNIQUE KEY。创建索引最常用的语句是：
CREATE INDEX idx_user_id ON orders(user_id);或者直接在 CREATE TABLE 里内嵌。而 FULLTEXT 是全文索引，适合对长文本做类似搜索的功能，注意这个索引类型只对 MyISAM 和 InnoDB 的部分场景生效，中文分词支持要看版本和插件。SPATIAL 是空间索引，处理地理位置数据才会用到，日常业务几乎不碰。
建索引这事看着简单，但“该建在哪一列”才是真正的学问。我自己判断是否建索引，会先看 WHERE、JOIN、ORDER BY 里高频出现且区分度高的列。区分度低就算了，比如性别字段建索引基本没用，因为每个值包含的行太多，MySQL 用索引不如直接扫表。
7. 表达式关键字：CASE WHEN、IFNULL、COALESCE 这些常用语法糖
7.1 CASE WHEN 的两种写法，不要只记住一种
CASE WHEN 是做条件分支的核心关键字。它有两种写法：
第一种是“表达式式”：
SELECT status, CASE status WHEN 'paid' THEN '已支付' WHEN 'pending' THEN '待支付' ELSE '未知' END AS status_text FROM orders;第二种是“条件式”：
SELECT amount, CASE WHEN amount >= 1000 THEN '大额' WHEN amount >= 100 THEN '中额' ELSE '小额' END AS amount_level FROM orders;两种写法都能用。第一种适合“某个字段的具体值决定输出”，第二种适合多个条件组合判断。实际写的时候注意：CASE 表达式按顺序匹配，一旦命中某个 WHEN 就结束，不会继续往下判断，所以从小范围到大范围，或者从高优先级到低优先级排列，是避免逻辑错误的关键。
7.2 IFNULL 和 COALESCE：处理 NULL 值时的选择
NULL 在 MySQL 里是个特殊存在，任何比较运算 IS NULL、IS NOT NULL，而用等号判断 NULL 永远不成立。数据的展示阶段，我最常用的是 IFNULL 和 COALESCE。
IFNULL 接收两个参数，如果第一个参数是 NULL，就返回第二个：
SELECT IFNULL(nickname, '匿名用户') FROM users;COALESCE 更灵活，可以接收多个参数，返回第一个非 NULL 值：
SELECT COALESCE(phone, email, '无联系方式') FROM users;我的习惯是，有多个候选值就用 COALESCE，只判断单个字段就 IFNULL。千万不要在 WHERE 里写IFNULL(name, '') = ''这种写法来替代name IS NULL OR name = ''，前者会让该字段的索引失效，查询性能直接下滑。
7.3 窗口函数关键字：OVER、PARTITION BY、RANK
如果 MySQL 版本到了 8.0，窗口函数是绕不开的亮点。它最常用的关键字组合是：函数名 + OVER + PARTITION BY + ORDER BY。比如给每个用户的订单按金额排名：
SELECT user_id, order_id, amount, RANK() OVER (PARTITION BY user_id ORDER BY amount DESC) AS rk FROM orders;PARTITION BY 的分组不同于 GROUP BY，它不会导致行数合并，而是每一行都保留，只是把“排名窗口”限制在分组内。这解决了很多以前必须用复杂自连接才能实现的“分组 top N”问题。我接手老项目时遇到类似需求，第一反应就是看版本支不支持窗口函数——能用 ROW_NUMBER() 解决的事，真的没必要写三层嵌套子查询。
8. 最后几个值得记住的细节关键字与个人经验
聊到现在，我想再补充几个日常高频但容易被忽略的细节，这些不算冷门，但很多人理解有偏差。
第一个是 DISTINCT。它用于去重，但它会作用于 SELECT 后面所有列的组合。SELECT DISTINCT a, b去重的是 (a,b) 组合，不是单独 a。想分组去重，优先考虑 GROUP BY，因为它更直观、更容易配合聚合函数。
第二个是 LIKE。它在数据量大的表上做%关键字%前缀匹配时，是走不了索引的。想加速模糊查询，要么考虑覆盖索引下用前缀匹配，要么用全文索引方案。别指望 LIkE 能既匹配又高效，这是底层索引结构决定的，不是调参能解决的。
第三个是 EXPLAIN 关键字，它不是 SQL 的一部分，但它分析 SQL。我每次遇到慢查询，第一步永远是EXPLAIN SELECT ...，看 type 列是不是 ALL（全表扫描），看 key 列是不是用了预期索引，看 rows 列估算是否离谱。这比盲猜加索引靠谱得多。
第四个是保留字问题。有些词，比如 KEY、ORDER、GROUP、DESC 这些，是 MySQL 的保留字或关键字，直接拿来做列名会报语法错误。实在要作为列名，可以用反引号包裹：
SELECT `order`, `key` FROM some_table;我的建议是建表时别给字段起这些名字，宁可改成 order_id、sort_key，省掉所有后续 SQL 里都要加反引号的麻烦。这和命名规范一样，属于前期一分钟、后期省一小时的事。
最后分享一个我自己的习惯：写复杂 SQL 前先在纸上或者注释里把执行顺序过一遍，标出 FROM 从哪里取数、WHERE 先过滤什么、GROUP BY 怎么分组、HAVING 还留下什么、ORDER BY 和 LIMIT 怎么截断。这套流程听着笨，但几乎能挡住所有“字段不在分组中”“别名找不到”“LEFT JOIN 变 INNER JOIN”的坑。等这些关键字和它们的执行规则融进肌肉记忆之后，写 SQL 的速度和准确率会同时上一个台阶，排查别人的遗留问题时也会从容很多。
