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 —— <code>DELETE不释放磁盘空间（只是标记删除），大表清理建议用
TRUNCATE或分区表方案； 所有 DML 若涉及多列赋值（如
UPDATE），列名与值必须严格一一对应，顺序错位不会报错但数据错乱。
大小写、空格与分号：看似琐碎，实则影响可读性与迁移性
MySQL 默认不区分关键字大小写（
select和
SELECT等效），但以下几点必须统一规范： 表名、列名在 Linux 系统上默认区分大小写（因文件系统敏感），Windows 下不敏感——跨平台项目务必全小写； 每个子句换行、关键词大写（如
SELECT、
FROM）、缩进对齐，能让你一眼看出嵌套层级； 每条语句结尾必须有分号
;，否则 MySQL 客户端会等待下一行输入，误以为语句未结束； 注释用
--（注意空格）或
#，多行用
/* ... */，避免在生产 SQL 中留调试用的未注释掉的
SELECT。
真正卡住人的，往往不是“会不会写”，而是“为什么这句没按我想象的跑”。结构意识到位了，看报错信息、查执行计划、调优索引，才都有了落脚点。
