企业官网建设流程全解析

说到 MySQL 常用关键字，很多人第一反应就是 SELECT、FROM、WHERE 这些“老三样”，背一遍好像就会了。可真到排查一条慢 SQL，或者被面试官追问“GROUP BY 和 HAVING 到底谁先执行”的时候，又会发现这些熟悉的关键字背后藏着一堆平时不会注意的细节。我这些年过手的项目里，因为关键字用法不当导致的慢查询、锁表、数据错乱案例比比皆是，这篇文章就把高频 MySQL 关键字的用法和原理按分类拆开讲一遍，重点放在“为什么这么写”和“实际怎么用”上。适合刚入门的新手，也给写过一阵子 SQL 但没系统梳理过的同学做个参考。

1. 查询与筛选类关键字：SELECT、FROM、WHERE的基本功

1.1 SELECT的执行顺序，和书写顺序并不是一回事

很多新手写 SQL 习惯从左到右读：SELECT 什么、FROM 哪张表、WHERE 怎么筛。但 MySQL 真正执行的时候，关键字顺序完全不是这样。标准 SQL 的逻辑执行顺序大致是：

1. FROM：确定数据来源，先找到表；
2. JOIN / ON：如果有连接，先做表连接；
3. WHERE：对连接后的结果做行级过滤；
4. GROUP BY：再按分组条件聚合；
5. HAVING：对分组后的组做过滤；
6. SELECT：最后才做投影，挑出要返回的列；
7. ORDER BY：排序；
8. LIMIT：取有限行。

理解这个顺序对排查问题特别有用。最常见的例子是：在 WHERE 里不能直接引用 SELECT 中定义的别名，因为 WHERE 执行时 SELECT 还没跑，别名根本不存在。而 ORDER BY 却可以用别名，因为排序发生在 SELECT 之后。

我之前处理过一个例子，某订单表要筛选出金额大于 100 的客户并按总额排序，有人写成WHERE total > 100，但 total 是 SELECT 里的SUM(amount) AS total，结果直接报“Unknown column”。正确写法是用 HAVING 或者再包一层子查询。理解执行顺序不是死记硬背，而是为了遇到报错和性能问题时知道去哪一层找原因。

1.2 WHERE 里的 NULL、隐式转换和 LIKE 陷阱

WHERE 是使用频率最高的关键字，但坑也最密集。

第一坑是 NULL 判断。WHERE name = NULL永远匹配不到数据，因为 NULL 参与等值比较的结果是“未知”，不是真也不是假。判断空值必须用IS NULL或IS NOT NULL。同理，NOT IN (子查询)遇到子查询结果里有 NULL 时，整个查询可能返回空集，这一点很多人踩过。

第二坑是隐式类型转换。当字段是字符串类型，查询条件却写成数字时，MySQL 会对字段做隐式转数字，比如WHERE phone = 13812345678，如果 phone 字段是 VARCHAR，这个查询可能无法正常使用索引，导致全表扫描。我看到过一张 500 万行的会员表，就因为电话号码少写了引号，查询从 0.01 秒变成 2 秒多。排查方法很简单，用 EXPLAIN 看 type 字段是不是从 const 或 ref 变成了 ALL。

第三坑是 LIKE 的转义。LIKE 中%表示任意多个字符，_表示任意单个字符。如果业务里真的要匹配包含这些符号的字符串，就得用ESCAPE指定转义符，例如LIKE '%\_%' ESCAPE '\\'。搜索类需求还要区分前缀匹配和模糊匹配，LIKE 'abc%'才有可能用索引，LIKE '%abc'基本告别索引。

1.3 DISTINCT 与 LIMIT：去重和分页要避开的两个坑

DISTINCT 的作用是对结果集去重，但它去重的是“整行”的投影结果。只对单列去重时要注意：SELECT DISTINCT name FROM user没问题，但SELECT DISTINCT name, age FROM user去重的是 name 和 age 的组合，不是只去 name。很多报表需求就要把这两个结果区分清楚。

DISTINCT 还有一个隐藏问题：它和 ORDER BY 联用时，排序字段必须在 SELECT 列表中，否则会报错或者结果不可控。例如SELECT DISTINCT name FROM user ORDER BY age，age 不在投影列表，MySQL 会报错，因为排序要基于去重后再排序，但 age 已经被丢掉了。

LIMIT 的坑主要在深分页。LIMIT 1000000, 20看起来只是取 20 条，但 MySQL 需要先把前 1000020 条数据都查出来，再丢掉前 1000000 条。数据量一大，这个 offset 会非常慢。我常用的替代方案是“上一页最大 ID 法”：先记录上一页最后一条记录的 id，然后WHERE id > 上一页最大id ORDER BY id LIMIT 20，配合主键索引走范围扫描，速度比OFFSET快一个数量级。如果业务必须用随机跳页，那就老老实实控制总数据量，或者考虑换搜索引擎方案。

2. 分组、排序与聚合关键字：GROUP BY、HAVING、ORDER BY

2.1 GROUP BY 的分组规则与 ONLY_FULL_GROUP_BY

GROUP BY 做的是“分组聚合”，分组之后每一组只保留一行结果。那么问题来了，SELECT 中如果出现既不是分组列、也不是聚合函数的字段，这个字段代表的是什么？

MySQL 5.7 之前默认允许这种写法，比如SELECT name, age FROM user GROUP BY name，如果一组里有多个不同的 age，返回的 age 是该组里“随机一条”的值，完全不可控。5.7 之后默认开启ONLY_FULL_GROUP_BY，这种 SQL 会直接报错。这其实是件好事，能逼着你把逻辑写清楚。

我在实际开发中常遇到两种情况：一是想知道一个用户分组下的所有订单号，这时候应该用GROUP_CONCAT(order_id)而不是直接 select 某个字段；二是想在分组结果中取某组内最大时间对应的那一行，这时候要写子查询或者用窗口函数，不能靠 GROUP BY 的“运气”。

这里还要补充一个细节：GROUP BY 在执行顺序上先于 SELECT，所以 GROUP BY 中也不能引用 SELECT 别名，除非 MySQL 的扩展行为让它“碰巧可用”，但最好不要依赖这种写法。分组列上有没有索引，直接决定它用不用临时表，EXPLAIN 里如果看到Using temporary就要警觉了。

2.2 WHERE 与 HAVING 的执行时机差异

WHERE 和 HAVING 都是过滤，但过滤对象完全不同。

WHERE 在分组之前、对行的原始数据过滤；HAVING 在分组之后、对聚合结果过滤。所以聚合条件必须放 HAVING，比如筛选订单总额大于 1000 的客户，写成HAVING SUM(amount) > 1000。如果把这个条件放 WHERE，MySQL 会直接报 Invalid use of group function。

反过来说，能放 WHERE 的条件就不要放 HAVING。比如“只统计已支付订单”，WHERE status = 'paid'可以在分组前把大量无关数据过滤掉，减少分组的数据量。如果放到 HAVING，MySQL 还是要先把所有状态的数据都分组，再做一次过滤，性能往往差很多。我优化过的一条统计 SQL，就是把 HAVING 里的状态条件挪到 WHERE，耗时从 800 毫秒降到 50 毫秒。

另外说一句，MySQL 对 HAVING 的支持比标准 SQL 宽松一些，它允许 HAVING 引用 SELECT 别名，甚至可以用 HAVING 做普通行的过滤。但这样写容易让人误解，还是建议规范使用：行过滤走 WHERE，组过滤走 HAVING。

2.3 ORDER BY 排序中的 NULL、自定义排序与随机排序

排序是每个应用都要面对的问题，但 ORDER BY 里有几个细节经常被忽略。

第一个细节是 NULL 值的位置。MySQL 默认排序规则是：ASC 升序时 NULL 排在最前面，DESC 降序时 NULL 排在最后面。这个行为和很多业务预期相反，比如按更新时间倒序，用户可能希望没有更新时间的记录排最后，结果它反而跑到最前面了。解决办法是显式控制：ORDER BY update_time IS NULL, update_time DESC，先按“是否为 NULL”排序，再按时间排。

第二个细节是自定义排序。状态字段经常需要按业务顺序排列，比如“处理中、已完成、已取消”，字母或字典序都不对，可以用FIELD(status, 'processing', 'done', 'cancelled')实现自定义顺序。但 FIELD 是个函数，放在排序字段上可能放弃索引，数据量大的时候要评估清楚。

第三个细节是慎用ORDER BY RAND()。这是典型的取随机行的写法，但它会对全表每一行生成随机数并排序，数据量上万就很痛苦。我一般用“随机主键法”：先查MAX(id)，然后生成一个随机 ID，再用WHERE id >= 随机id LIMIT 1去取。虽然不是绝对均匀，但性能比 RAND() 高两个量级。

3. 多表连接与集合运算关键字：JOIN、UNION、IN、EXISTS

3.1 JOIN 的几种写法与 on/where 过滤条件的位置

JOIN 类关键字包括 INNER JOIN、LEFT JOIN、RIGHT JOIN、CROSS JOIN 等。很多人只知道 LEFT JOIN 是“左表全保留，右表没匹配就补 NULL”，但很容易忽略 ON 和 WHERE 条件的区别。

对于 INNER JOIN，ON 和 WHERE 里放过滤条件结果看起来差不多，但语义上 ON 管连接，WHERE 管输出前过滤。对于 LEFT JOIN，区别就非常大。比如订单表 left join 用户表，想查所有订单并附带用户昵称，如果业务只需要“已激活用户”的订单，有人会写成：

SELECT * FROM orders o LEFT JOIN users u ON o.user_id = u.id WHERE u.status = 'active';

这个 SQL 的逻辑是用 LEFT JOIN 保留所有订单，但 WHERE 把右表为 NULL 的行全部删掉了，实际效果和 INNER JOIN 完全一样。如果需求真的是“所有订单，未激活用户显示为 NULL”，条件应该写在 ON 里：

SELECT * FROM orders o LEFT JOIN users u ON o.user_id = u.id AND u.status = 'active';

这两个结果在有未激活用户时差得很远。实践里我见过不少因为这俩位置搞错导致的报表数据缺失，而且很难发现，因为主表数据量大的时候差异会藏在角落里。

连接性能上还有一个概念：驱动表和被驱动表。MySQL 通常用小表驱动大表，尽可能让被驱动表的连接列走索引。写 JOIN 时如果发现 EXPLAIN 里被驱动表 type 是 ALL，就要检查连接列有没有索引。

3.2 UNION 与 UNION ALL 的去重和排序差异

UNION 和 UNION ALL 都是把多个 SELECT 的结果纵向拼在一起，区别是 UNION 默认会去重，UNION ALL 不去重。

去重听起来很美好，但代价很大。UNION 的实现通常需要创建临时表，对结果做去重甚至排序。如果两个查询本就互斥，或者业务上允许重复，就完全没有必要用 UNION。比如汇总多个子公司的销售数据，各子公司数据天然独立，用 UNION ALL 就够了。我一个同事把统计报表里的 UNION 换成 UNION ALL 后，接口耗时从 3 秒降到 0.4 秒，差距非常明显。

UNION 还有两个使用上的硬性规则：每个 SELECT 的列数必须相同，对应列的数据类型尽量兼容；默认列名来自第一个 SELECT。如果要给整个 UNION 结果排序或分页，标准写法是包一层子查询：

SELECT * FROM ( SELECT id, name FROM t1 UNION ALL SELECT id, name FROM t2 ) tmp ORDER BY id DESC LIMIT 10;

不包子查询直接把 ORDER BY 写在最后一个 SELECT 后面，在不同数据库里行为不一致，建议一律用子查询包裹，逻辑清晰也不容易踩坑。

3.3 IN 子查询与 EXISTS 的选择逻辑

IN 和 EXISTS 都能表达“一张表中的数据是否匹配另一张表”，但很多开发者对这俩的取舍还是靠感觉。

简单记一个经验：当子查询结果集很小、外层表数据量大时，IN 通常更合适；当子查询结果集很大、外层表数据量小时，EXISTS 有时更有效。但实际上 MySQL 优化器对 IN 子查询会做半连接优化，会把子查询转成临时表再和外层连接，不一定非要用 EXISTS。反过来，EXISTS 常用于关联子查询，因为它在某些场景下能利用索引提前“短路”。

我用过一个案例：一张订单流水表 1000 万行，一张黑名单表 2 万行，要过滤出黑名单用户的订单。用WHERE user_id IN (SELECT user_id FROM blacklist)时 MySQL 选择了半连接，性能很好。但如果子查询里还有复杂聚合，或者两表关联条件没有索引，EXISTS 可能更快。所以最好的做法不是死记口诀，而是把两条 SQL 都写上，用 EXPLAIN 看执行计划，再用实际数据量压测。

另外一个和 IN 有关的坑：IN 列表里不要有 NULL，一旦有 NULL，NOT IN的结果会变成空集。每次遇到 NOT IN 我都会下意识检查子查询的结果是否可能为 NULL，如果可能，就改用NOT EXISTS。

4. 数据写入与表结构维护关键字：INSERT、UPDATE、DELETE、ALTER

4.1 INSERT 的批量写入、重复键处理与 REPLACE 陷阱

INSERT 是写入数据最常用的关键字，但它的“姿势”直接影响数据库性能。

第一，批量插入尽量用一条语句带多个 VALUES。比如插入 1000 行，写成INSERT INTO t (a,b) VALUES (1,1),(2,2)...，比循环 1000 次单条 INSERT 快很多，因为减少了客户端和 MySQL 的交互次数以及日志刷盘开销。我见过一个初始化任务，循环写入两万条耗时十几分钟，改成每 500 条一批后，三十秒跑完。

第二，处理重复键时要分清需求。业务希望“存在就更新，不存在就插入”，可以用INSERT ... ON DUPLICATE KEY UPDATE。注意这个关键字依赖唯一索引或主键冲突来触发更新。比如：

INSERT INTO user_stat(user_id, cnt) VALUES(1001, 1) ON DUPLICATE KEY UPDATE cnt = cnt + 1;

这条 SQL 可以安全地做计数累加，很适合点击量统计场景。但它有一个容易被忽略的特点：如果只更新某些字段，其余字段会保留原值，不会重置。

第三，REPLACE INTO 是另一个陷阱。它的逻辑是“先判断唯一冲突，冲突就先 DELETE 旧行再 INSERT 新行”。这会导致自增主键 ID 变化，还会触发外键或相关表的删除动作。如果表上有其他业务引用这个主键，后果很严重。所以我的原则是：能用 ON DUPLICATE KEY UPDATE 就不用 REPLACE INTO。

4.2 UPDATE 和 DELETE 的常见翻车点

UPDATE 和 DELETE 的翻车点核心就一个：条件不严谨。

UPDATE t SET status = 1没有 WHERE，会把全表状态改掉。DELETE FROM t没有 WHERE，会清空全表。这类事故在开发环境发生还好，在生产环境就是灾难。我见过影响线上业务的案例：一条漏了 WHERE 的 UPDATE 把订单状态全部置为已支付，最后只能靠备份恢复。所以在执行 UPDATE/DELETE 之前，我习惯先写等价的 SELECT COUNT(*) 看一眼影响行数，确认范围后再改写成 UPDATE/DELETE。

DELETE 还有一个 MySQL 特有的限制：如果给表起别名，有的版本会报错。比如DELETE FROM orders WHERE id IN (SELECT ...)没问题，但DELETE o FROM orders o WHERE ...的写法需要把别名放在 DELETE 后。多表删除时更要注意，语句可以同时删除多张表的数据，条件一旦写错就把关联表的数据都删了。

TRUNCATE 是 DELETE 的近亲，但它不是简单的删除。它不能带 WHERE，属于 DDL 操作，会重置自增 ID，速度非常快但通常不能被事务回滚。生产中清空表前一定要区分 TRUNCATE 和 DELETE 的语义。

4.3 ALTER TABLE 的 ADD、MODIFY、CHANGE、DROP 实操要点

ALTER TABLE 用来改表结构，关键字也不少：ADD 加列、MODIFY 改列类型、CHANGE 改列名和类型、DROP 删列、RENAME 改表名。看起来简单，实际生产环境最怕的就是 ALTER。

一个核心问题是锁表。MySQL 5.6 之前很多 DDL 操作需要锁表，即使后来支持了 INSTANT 和 INPLACE 算法，也并非所有操作都能在线完成。比如修改列类型通常需要重建表，数据量大的时候会长时间锁写，影响线上业务。我处理过一张 500 万行的日志表，凌晨执行ALTER TABLE ADD COLUMN都用了十几分钟，期间服务出现大量写入超时。

实操中建议养成三个习惯：

1. 变更前先看当前表大小和数据量，用SHOW TABLE STATUS或 information_schema 估算影响；
2. 指定算法和锁策略，例如ALTER TABLE t ADD COLUMN c INT, ALGORITHM=INSTANT, LOCK=NONE，让 MySQL 在不支持时直接报错而不是偷偷退化；
3. 大表结构变更不要在业务高峰执行，必要的话利用低峰期或分批处理。

MODIFY 和 CHANGE 的区别也经常有人搞混。MODIFY 只能改类型或属性，不能改列名；CHANGE 可以同时改列名和类型，但即使只改类型，也必须带上旧列名和新列名两个参数，写漏了会报错。

5. 索引与约束关键字：INDEX、UNIQUE、PRIMARY KEY、FOREIGN KEY

5.1 索引关键字到底怎么选：普通索引、唯一索引、全文索引

索引相关的关键字包括 INDEX、KEY、UNIQUE、FULLTEXT、SPATIAL 等。KEY 和 INDEX 在 MySQL 里基本是一回事，习惯上建表时用 KEY，单独建索引时用 INDEX。

普通索引就是加速查询，不限制重复值；唯一索引在加速之外还保证列值或列组合不重复；全文索引用于对文本内容做全文检索；空间索引用于地理数据。很多业务在用户表建索引时，直接把用户名设成 UNIQUE，这本没错，但要注意唯一索引对写入性能的影响：每次插入都要做唯一性检查，写并发高的表不要为了“省事”到处加唯一索引。

组合索引是另一个高频话题。创建INDEX idx_user_status_time (status, create_time)，它能服务哪些查询？按最左前缀原则，条件里有 status、或者 status + create_time 都能用这个索引，但只查 create_time 不行。设计索引时要“数一下”查询条件里哪些字段是稳定等值条件，把它们放最左边，把范围条件放后面，才能发挥索引合并和排序的作用。

另外，索引不是越多越好。每次写入都会同步维护索引，索引多了写入就慢，还占磁盘。我给业务加索引之前一定会问：这个查询是不是真实的、频繁的、对性能敏感的？如果一条 SQL 一天就一两次，加索引可能得不偿失。

5.2 约束关键字背后的代价：外键为什么经常被禁用

约束关键字包括 PRIMARY KEY、UNIQUE、NOT NULL、DEFAULT、FOREIGN KEY、CHECK。PRIMARY KEY 和 UNIQUE 是最常见的，一个表只能有一个主键，但可以有多个唯一键。

外键是我特别想提醒的一个点。理论上外键能保证引用完整性，比如订单表的 user_id 对应到用户表的 id，加上 FOREIGN KEY 后，如果用户不存在就插不进订单。这看起来很美好，但生产架构里很多团队故意不用物理外键，原因有三：

一是性能开销。每次插入和更新订单都会触发外键检查，还要对父表加共享锁，写入并发高时容易引发锁等待和性能下降。 二是死锁风险。多表操作涉及多个行锁和表锁，外键约束让锁的获取顺序更复杂，更容易出现死锁。 三是运维困难。删除父表数据或做数据归档时，外键会处处“卡脖子”，成群结队的报错。

这不是说外键一无是处，而是在拆分服务、分库分表后，跨库外键根本无法使用。所以多数团队选择在应用层保证关联完整性。如果你在单机小系统里，且开发团队纪律不够强，物理外键反而是保护数据的一道防线。两种取舍都有道理，关键是明白代价。

5.3 结合 EXPLAIN 判断关键字设计是否合理

写再多的关键字建议，最终都要用 EXPLAIN 来验证。EXPLAIN 不是关键字本身，而是查看执行计划的利器。

一条慢查询最常见的问题是索引没生效。EXPLAIN 输出里的 type 字段需要重点关注，从好到差大致是：system、const、eq_ref、ref、range、index、ALL。看到 ALL 意味着全表扫描，大多数情况下都是问题。

还有几个字段值得看：

• possible_keys：理论上可能用到的索引；
• key：实际选中的索引；
• key_len：用了索引前缀多长；
• rows：预估扫描行数；
• Extra：如果出现 Using filesort 或 Using temporary，说明排序和分组没走好索引，常常需要优化。

我曾排查一条SELECT * FROM order_detail WHERE status = 1 AND order_id = 123 ORDER BY create_time的慢查询，表上有 status 和 order_id 各自的单列索引。结果 MySQL 选错了索引，只用了 status 的索引，回表后又 filesort。解决方案是建一个(order_id, status, create_time)的组合索引，让 WHERE 三个条件和排序全部命中索引，查询直接从 200ms 降到 1ms。这类问题用 EXPLAIN 一看就明白，根本不需要猜。

6. 与关键字相关的常见报错和避坑实录

6.1 保留字做字段名，报错不是一般的怪

MySQL 有一批保留字，比如 order、group、desc、select、where、condition 等。如果你建表时不小心用了保留字做字段名，SQL 写出来往往报语法错误，而且报错位置很迷惑，一时半会儿看不出来是字段名的问题。

我见过一个订单表，字段叫desc，本意是描述，结果所有查询都报错。解决方法是给字段名加反引号：SELECT \desc` FROM t。但更根本的解决方案是建表时避开保留字，用description、order_status、group_name` 这类语义清晰的命名。

这里也提醒一个命名习惯：不要用name、type、key这种哪个系统都觉得眼熟的词，容易在不同数据库之间迁移时踩雷。名称里最好带业务前缀，比如user_name、order_status，既可读又降低保留字冲突概率。

6.2 sql_mode 设置引发的三个老坑

MySQL 的行为受 sql_mode 影响非常大，而很多团队装完数据库后根本没管过这个参数。

第一个是 ONLY_FULL_GROUP_BY。前面提到过，默认开启后严格检查 GROUP BY 列。老项目从 5.6 升到 5.7 或 8.0，如果 SQL 写得不规范，突然全挂，这是最常见的升级事故。

第二个是 NO_ZERO_DATE 和 NO_ZERO_IN_DATE。这类模式不允许日期中出现 0000-00-00 或 2023-00-01。很多老系统插入日期时用的是空字符串转日期，结果在严格模式下直接报错。处理办法不是盲目关掉模式，而是修复脏数据。

第三个是 STRICT_TRANS_TABLES。它把“字段超长自动截断”变成了“直接报错”，比如一个 varchar(10) 字段插入 15 个字符，非严格模式下会截断并警告，严格模式下直接失败。遇到这种问题，先看是不是业务数据本身异常，而不是急着改模式。

想查看当前模式：SELECT @@sql_mode;，想临时改：SET sql_mode = '...';，但重启后会丢失，生产环境必须通过配置文件固化。

6.3 表名大小写与字符集排序规则对关键字行为的影响

MySQL 关键字本身是不区分大小写的，SELECT、select、Select 都能执行。但表名和数据库名在 Linux 下区分大小写，在 Windows 下默认不区分，这跟一个系统参数 lower_case_table_names 有关。

如果你在 Linux 上建表用UserInfo，然后代码里写userinfo，大概率报“Table doesn't exist”。很多项目从 Windows 开发机迁到 Linux 服务器时踩过这个坑。建议团队统一规范：所有表和字段一律小写、下划线分隔，这样环境差异基本不影响。

字符集和排序规则也会影响关键字相关操作，尤其是 ORDER BY 和 GROUP BY 的排列顺序。utf8mb4_general_ci 不区分大小写，utf8mb4_bin 区分大小写。同样是 ORDER BY name，两张表可能排出不同结果。如果两个字段来自不同字符集，JOIN 时还可能出现“Illegal mix of collations”报错。解决办法是统一库、表、字段的字符集和排序规则，最好在建库时就定好 utf8mb4 + utf8mb4_0900_ai_ci 这一套。

6.4 隐藏的隐式类型转换，EXPLAIN 一眼看穿

最后一个常见坑，也是我几乎每次性能调优都会检查的：隐式类型转换。它不会像语法错误一样直接报错，而是悄悄地把索引废掉，让你看到慢查询又找不到原因。

最典型的是字符串字段和数字比较。比如用户表里的手机号是 varchar，但查询写WHERE phone = 13812345678，MySQL 会尝试把 phone 转成数字再比较，导致 phone 上的索引失效。如果反过来写WHERE id = '123'，是把字符串转数字，通常不影响查询，因为 MySQL 会把值转成字段类型再走索引。

还有一种情况是日期字段和字符串比较。WHERE create_time >= '2024-01-01'通常没问题，但如果写成WHERE create_time >= 20240101，某些场景下会做隐式转换，导致无法有效利用索引。

遇到这类问题，最直接的办法是 EXPLAIN 看 type 和 key。如果明明有索引但 key 是 NULL，或者 rows 很大，优先检查是不是类型转换、函数包裹字段、字符集不一致。把查询条件改成与字段类型一致的写法，很多慢 SQL 当场就治好了。

我个人在实际操作中的体会是：MySQL 关键字本身不难，难的是把它放到真实的数据量、真实的索引结构、真实的并发场景里。每一个关键字背后都有对应的执行逻辑和取舍，写 SQL 之前多想一步“这条语句会被怎么执行”，远比自己背语法有效得多。希望这篇整理能帮你少踩几个坑。