mysql基础语法围绕“数据库→表→数据”三层结构，核心是ddl（建库建表）、dml/dql（增删改查）、where/order by（条件排序）、聚合函数四类操作；建库需加if not exists和utf8mb4字符集，建表须明确定义主键与非空约束；insert/select务必显式指定字段名，避免结构变更导致报错；where条件中字符串必须加引号以防隐式转换致索引失效；group by与having不可互换，因执行顺序不同且having可使用聚合函数而where不可。
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，多问一句：“它会在哪一步出错？索引还能用吗？数据量翻十倍还扛得住吗？”——这比背一百条语句管用得多。
