MySQL SQL规范要求关键字大写、字段小写以提升可读性与兼容性；多表查询需换行缩进、显式别名；WHERE条件分组加括号并换行对齐；SELECT禁用*，字段按业务语义显式列出并命名。
关键字大写 + 字段小写是最低成本的可读性提升
MySQL 不校验大小写，但人眼需要视觉锚点。把 SELECT、FROM、WHERE 这类词全大写，立刻能区分出语法结构；而 user_id、created_at 这类字段名统一小写，避免和保留字混淆或引发隐式转换风险。
常见错误现象：有人写 select UserID, CreatedAt from Users，结果在另一台环境因大小写敏感（比如启用了 lower_case_table_names=0）直接报错 Table 'Users' doesn't exist；更糟的是，团队里有人习惯驼峰，有人用下划线，查个 order_status 还得翻表结构确认是不是叫 orderStatus。
- 所有关键字强制大写：
SELECT、INNER JOIN、GROUP BY、HAVING、ORDER BY - 表名、字段名、别名全部小写，单词间用下划线：
user_profile、is_active - 禁止混用：不接受
Select u.Name From users这种“首字母大写+其余小写”的中间态
多表查询必须换行缩进 + 显式别名
一行写完的 SELECT * FROM users u, orders o WHERE u.id = o.user_id AND o.status = 1 看似省事，但只要加一个 LEFT JOIN user_address ua ON ua.user_id = u.id，整条语句就变成横向滚动灾难。缩进不是为了美观，是为了让“谁连谁”“条件在哪生效”一目了然。
使用场景：日常排查慢查时，DBA 或后端同事拿到 SQL 第一反应是看 JOIN 链是否合理、ON 条件有没有漏——如果所有内容挤在一行，光找 ON 就要扫三遍。
- 每个子句独占一行：
SELECT、FROM、JOIN、ON、WHERE、GROUP BY各自成行 - JOIN 后的
ON必须缩进一层，且字段前带别名：ON o.user_id = u.id，不接受ON orders.user_id = users.id - 别名长度控制在 2–3 字母，语义明确：
u表 users，o表 orders，up表 user_profile；禁用a、t1、tmp
WHERE 条件要分组加括号 + 换行对齐
当条件超过三个，WHERE status = 1 AND is_deleted = 0 AND role IN ('admin', 'editor') AND updated_at > '2024-01-01' 这种写法会让“逻辑分组”完全消失。一旦要临时注释掉某一段（比如先排除 role 过滤），很容易漏括号或逗号，导致语法错误或语义错误。
性能影响：括号本身不改变执行计划，但能防止你手抖改错优先级。比如 AND (role = 'admin' OR role = 'editor') AND status = 1 和 AND role = 'admin' OR role = 'editor' AND status = 1 结果完全不同。
- 语义相关条件放一组，用括号包裹：
(u.status = 1 AND u.is_deleted = 0) - 每组条件换行，且
AND/OR放行首对齐，方便增删整行 - 避免嵌套过深：超过两层括号（如
((a AND b) OR (c AND d)) AND e）建议拆成 CTE 或临时表，别硬撑
SELECT 列表禁用 *，字段顺序按业务语义排列
SELECT * 在开发阶段看似省事，上线后就是定时炸弹：表加了个 content TEXT 字段，接口响应时间从 20ms 涨到 800ms；或者某天 DBA 把 password_hash 字段挪到了第 5 位，下游用 rs.getString(3) 取邮箱的代码直接取错字段。
容易踩的坑：有人觉得“反正 ORM 自动生成”，但日志里打出来的 SQL、监控平台抓到的慢查、DBA 手动 EXPLAIN 的语句，全是裸 SQL —— 这些地方没人帮你转成对象。
- 永远显式写出字段名：
SELECT u.id, u.username, u.email，不接受SELECT * - 字段顺序按前端/业务需要排列，不是按建表顺序：比如用户列表页优先展示
username、email、status，那就按这个顺序写，别把created_at放最前 - 计算字段或函数结果必须显式命名：
COUNT(o.id) AS order_count，不接受COUNT(*)这种无名输出
实际协作中最容易被忽略的，是“字段顺序按业务语义排列”这一条——它不报错、不慢、不难写，但当某天产品说“用户列表页要把手机号提到第二列”，你得挨个去改十几处 SQL 的字段顺序，而不是只改一句 SELECT。
