MySQL 基础语法不是一堆抽象规则，而是围绕「数据库→表→数据」三层结构展开的几类核心操作：建库建表（DDL）、增删改查（DML/DQL）、条件与排序（WHERE / ORDER BY）、聚合计算（COUNT/SUM/AVG 等）。掌握这四类，就能覆盖 90% 的日常使用场景。
CREATE DATABASE 和 CREATE TABLE 怎么写才不报错
建库和建表是所有操作的前提，但新手常因忽略字符集、主键、非空约束而后续插入失败或乱码。
CREATE DATABASE建议始终加
IF NOT EXISTS和显式字符集：
CREATE DATABASE IF NOT EXISTS mydb DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;—— 避免重复创建报错，且
utf8mb4支持 emoji 和生僻字
CREATE TABLE中字段必须声明类型，主键建议用
INT UNSIGNED AUTO_INCREMENT PRIMARY KEY，字符串字段别只写
VARCHAR(255)，要加
NOT NULL（除非真允许为空） 常见错误：
ERROR 1071 (42000): Specified key was too long—— 通常是
VARCHAR字段过长 + 使用了
utf8mb4导致索引超限，可将长度缩至
VARCHAR(191)或改用前缀索引
INSERT 和 SELECT 最容易踩的坑在哪
INSERT和
SELECT是每天敲得最多的语句，但细节决定成败。 全列插入时省略字段名看似方便：
INSERT INTO user VALUES (1,'Alice','alice@x.com');—— 一旦表结构变更（比如中间加了个
created_at字段），这条语句立刻报错。强烈建议显式写出字段：
INSERT INTO user (id, name, email) VALUES (1,'Alice','alice@x.com');
SELECT *在开发调试时省事，但生产环境禁止使用：它会把所有字段（包括大文本、JSON、BLOB）都拉过来，浪费网络和内存；更危险的是，如果表新增了敏感字段（如
password_hash），
*会悄无声息地把它也查出来 别忘了
WHERE子句——漏写会导致全表更新或删除：
UPDATE user SET status='inactive';（没加
WHERE id=123）可能让整个用户表“躺平”
WHERE 条件里字符串和数字怎么比才安全
MySQL 会做隐式类型转换，看着能跑，实则埋雷。
字段是VARCHAR类型（比如
phone CHAR(11)），查询时却写
WHERE phone = 13812345678（无引号）——MySQL 会把字符串字段转成数字再比，导致索引失效，全表扫描 正确写法永远加引号：
WHERE phone = '13812345678'；同理，时间字段如
created_at DATETIME，务必用
'2025-01-01'而不是
20250101模糊匹配用
LIKE时，
%abc%无法走索引，
abc%可以；想查邮箱后缀？
WHERE email LIKE '%@gmail.com'是性能杀手，应考虑倒排或单独建字段
GROUP BY 和 HAVING 为什么不能互换
这是 SQL 执行顺序导致的硬性限制，不是风格问题。
WHERE在分组前过滤行，
HAVING在分组后过滤组——所以
HAVING能用聚合函数（如
COUNT(*) > 5），
WHERE不能 MySQL 5.7+ 默认开启
sql_mode=ONLY_FULL_GROUP_BY，意味着
SELECT a, b, COUNT(*) FROM t GROUP BY a会报错（
b不在
GROUP BY中也不在聚合函数里）；要么补全
GROUP BY a,b，要么明确用
ANY_VALUE(b)表明你接受任意值 别试图用
WHERE COUNT(*) > 1替代
HAVING—— 语法直接拒绝，因为
WHERE阶段还不存在
COUNT(*)
真正卡住人的往往不是语法记不住，而是执行顺序（FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT）和隐式行为（比如字符串自动转数字、
GROUP BY的严格模式）带来的意外结果。写完每条 SQL，多问一句：“它会在哪一步出错？索引还能用吗？数据量翻十倍还扛得住吗？”——这比背一百条语句管用得多。
