MySQL SQL语句分为DDL、DML、DQL、DCL四类，分别管理结构、数据、查询和权限；SELECT五段式有严格执行顺序：WHERE→GROUP BY→HAVING→SELECT→ORDER BY→LIMIT。

MySQL 的 SQL 语句不是一堆随意拼凑的单词，而是有明确分层结构、各司其职的逻辑组合。理解它的整体组成，比死记单条命令更能帮你快速定位错误、写出可维护的语句。

SQL 语句按功能划分为四大类（DDL/DML/DQL/DCL）

每类解决一类问题，混用或错用会导致语法报错或行为异常：

• DDL（Data Definition Language）：管“骨架”——创建/修改/删除数据库、表、索引等结构。典型命令：CREATE DATABASE、ALTER TABLE、DROP INDEX。执行后不走事务（多数引擎下不可回滚）。
• DML（Data Manipulation Language）：管“血肉”——增删改数据。核心是 INSERT、UPDATE、DELETE。它们默认在事务中运行，可 COMMIT 或 ROLLBACK。
• DQL（Data Query Language）：只读“眼睛”——唯一以 SELECT 为核心的类别。哪怕带 WHERE、GROUP BY，本质仍是查询，不改变原始数据。
• DCL（Data Control Language）：管“门禁”——控制谁能看到/改什么，如 GRANT SELECT ON user TO 'dev'@'localhost'。权限变更即时生效，不依赖事务。

一条标准 SELECT 语句的五段式结构（DQL 典型代表）

它不是线性堆砌，而是有执行顺序和依赖关系的流水线：

SELECT [DISTINCT] col1, col2, COUNT(*) AS cnt
FROM table_a
[JOIN table_b ON ...]
WHERE col1 > 100
GROUP BY col2
HAVING cnt > 5
ORDER BY cnt DESC
LIMIT 10;

• WHERE 在 GROUP BY 之前执行：过滤的是原始行，不能用聚合结果（如 COUNT(*)）；
• HAVING 必须跟在 GROUP BY 后：过滤的是分组后的结果集，可安全使用 COUNT(*)、AVG() 等；
• SELECT 列表中的别名（如 cnt）在 ORDER BY 中可用，但在 WHERE 或 HAVING 中不可用（执行顺序靠后）；
• LIMIT 是最后执行的——它截断的是最终排序后的结果，不是中间过程。

INSERT/UPDATE/DELETE 的共性结构与关键陷阱

这三类 DML 语句表面简单，但漏写 WHERE 或写错条件，后果往往是灾难性的：

• INSERT INTO t(col1,col2) VALUES (1,'a'),(2,'b'); —— 批量插入效率远高于多条单行语句；
• UPDATE t SET status='done' WHERE id IN (1,2,3); —— 永远显式加 WHERE，否则整表更新；测试前先用 SELECT 验证条件是否命中预期行；
• DELETE FROM t WHERE created_at —— DELETE 不释放磁盘空间（只是标记删除），大表清理建议用 TRUNCATE 或分区表方案；
• 所有 DML 若涉及多列赋值（如 UPDATE），列名与值必须严格一一对应，顺序错位不会报错但数据错乱。

大小写、空格与分号：看似琐碎，实则影响可读性与迁移性

MySQL 默认不区分关键字大小写（select 和 SELECT 等效），但以下几点必须统一规范：

• 表名、列名在 Linux 系统上默认区分大小写（因文件系统敏感），Windows 下不敏感——跨平台项目务必全小写；
• 每个子句换行、关键词大写（如 SELECT、FROM）、缩进对齐，能让你一眼看出嵌套层级；
• 每条语句结尾必须有分号 ;，否则 MySQL 客户端会等待下一行输入，误以为语句未结束；
• 注释用 -- （注意空格）或 #，多行用 /* ... */，避免在生产 SQL 中留调试用的未注释掉的 SELECT。

真正卡住人的，往往不是“会不会写”，而是“为什么这句没按我想象的跑”。结构意识到位了，看报错信息、查执行计划、调优索引，才都有了落脚点。