MySQL 的 SQL 语句不是一种编程语言，而是一套结构化、面向操作的指令集，专用于与关系型数据库交互。它本身不编译、不运行，而是由 MySQL 服务器解析执行；你写的每一条
SELECT、
INSERT、
UPDATE，本质都是向服务端发出的一个“请求动作”。
怎么写一条能跑通的 SELECT 查询？
最基础的查询必须包含两个核心部分：
SELECT字段列表 +
FROM表名。缺一不可，否则会报错
ERROR 1064（语法错误）。
SELECT *看起来省事，但生产环境应避免——表字段一多，网络传输和内存开销直线上升 指定字段更安全，比如
SELECT id, name, created_at FROM users如果字段名或表名含特殊字符或关键字（如
order），必须用反引号包裹：
<code>order别名用
AS可省略，但带空格时必须加引号：
SELECT name AS '用户姓名' FROM users
WHERE 条件写不对，查出来全是“幻觉数据”
没加
WHERE就是全表扫描；加了但逻辑错，结果可能完全偏离预期——比如把
AND写成
OR，或忽略
NULL的三值逻辑。
WHERE status = 'active'查不到
status为
NULL的记录，因为
NULL = 'active'结果是
UNKNOWN，不进入结果集 正确判断空值用
IS NULL或
IS NOT NULL，不能用
= NULL字符串模糊匹配别漏掉
LIKE的通配符：
WHERE name LIKE '%李%'（
%匹配任意长度），而
_只匹配单个字符 多条件优先级易错：建议显式加括号，比如
WHERE (type = 'vip' OR type = 'admin') AND deleted = 0
LIMIT 和 OFFSET 不是“翻页万能解”，小心深分页性能崩塌
LIMIT 10 OFFSET 10000看似只是跳过前 1 万条取 10 条，但 MySQL 仍要完整扫描并排序前 10010 行——数据量一大，响应直接卡死。 深分页替代方案：用上一页最后一条的主键值做游标查询，例如
WHERE id > 12345 LIMIT 10
LIMIT后不跟
ORDER BY是危险的：无序结果下，同一条语句多次执行可能返回不同行 偏移量为 0 可省略，
LIMIT 10等价于
LIMIT 10 OFFSET 0
真正的难点不在语法本身，而在理解「每条 SQL 背后对应怎样的数据扫描路径」——很多慢查询，问题不出在写法多炫酷，而出在没意识到自己正让数据库做全表扫描。
