大家好，我是晚安code。
假设一个场景一条慢查询，单表两千万行，`WHERE status = ?` 一条简单过滤跑了 8 秒。`EXPLAIN` 一看 type 是 `ALL`，全表扫描。原因说出来你可能不信：`status` 字段是 varchar，代码里传了个 int，MySQL 一隐式转换，索引直接作废。这种坑，MySQL 开发规范里几乎每条都在提醒你。
![image](https://developer.qcloudimg.com/http-save/yehe-12591818/d56ad5d14c7f26c5b140f6a4f03b1168.webp)这种坑，我把建表、索引、SQL、ORM 四块最要命的强制项整理成这份清单（2026 年 8 月整理，以 MySQL 8.0 为基线）。**MySQL 开发规范里最值钱的一条经验是：表一旦上线，字段名和类型基本就改不动了**，所以每一行 DDL 都值得你认真写。
先点个收藏，咱们一条条过。
## 一、建表规约：命名的坑，从第一行 DDL 就开始了

**MySQL 建表规范里，命名是最容易被忽略、又最难改的部分。** 字段名一旦上线被业务引用，改起来牵一发动全身，还没法预发布，所以规范第一条就是"想清楚再建"。
几个强制项先记下来：
1）布尔字段一律用 `is_xxx` 命名，类型是 `unsigned tinyint`，1 表示是、0 表示否。别用 `status` 猜来猜去，`is_deleted` 一眼就知道是逻辑删除标记。
2）表名、字段名全小写，禁止大写、禁止数字开头、禁止两个下划线夹数字。MySQL 在 Windows 下不区分大小写，Linux 下区分——一旦部署到 Linux，`AliyunAdmin` 和 `aliyun_admin` 就是两张表。我同事当年就是在这里摔过一跤。
![image](https://developer.qcloudimg.com/http-save/yehe-12591818/6f246d2e19e5fbb0b1670b0a2284b845.webp)3）表名单数形式，`user` 而不是 `users`，跟 DO 类名保持一致。
4）禁用保留字，`desc`、`range`、`match` 这些都不能当列名。
5）索引命名统一：主键 `pk_字段名`，唯一索引 `uk_字段名`，普通索引 `idx_字段名`。看名字就知道索引类型，排查问题时省一半力气。
![乱命名 vs 规范命名，一眼看区别](https://developer.qcloudimg.com/http-save/yehe-12591818/91f06c2062dd2812db376614fff6aeb6.png)乱命名 vs 规范命名，一眼看区别接着是类型。**小数一律用 decimal，禁止 float 和 double**——float/double 是二进制近似存储，对账经常对出几厘钱的误差。金额、汇率这种一存 float，线上对不平只是时间问题。
字符串类型看长度：长度几乎相等用 `char` 定长，长度不确定用 `varchar`，但 varchar 别超过 5000。超长文本（如商品详情）拆出来单独一张表用主键关联，别硬塞在主表里拖垮索引率。
每个表必备三字段：`id`（bigint unsigned 主键自增）、`create_time`、`update_time`（datetime 类型，要记时区就用 timestamp）。没有 update_time 的表，出了数据问题你连"什么时候改的"都查不到。
然后是争议最大的一条——**逻辑删除**。
**逻辑删除**：不物理删除记录，而是用标记字段（如 `is_deleted=1`）表示已删除，相当于给数据加了"回收站"。好处是数据可追溯，坏处是原本唯一的键可能不唯一，需要根据业务场景另行处理。
这里常有人纠结"删了就是删了，留个标记干嘛"。我把两条路的取舍画成一张表：

        
          
|维度|物理删除|逻辑删除|
|:-:|:-:|:-:|
|数据可追溯|不可恢复|可追溯操作记录|
|唯一性约束|无冲突|需处理唯一键复用|
|存储占用|省空间|多占一行标记|
|查询复杂度|简单|每处 WHERE 都带 is_deleted|
|适用场景|临时表、可重建数据|核心业务数据、需审计|

        
      我的态度很明确：核心业务表一律逻辑删除，临时表随便物理删。别省那点空间，丢了用户订单数据你哭都来不及。
![撕掉就没了，贴标签还能找回来](https://developer.qcloudimg.com/http-save/yehe-12591818/c83f0e6e8e00f785f240a86a8b6571cb.png)撕掉就没了，贴标签还能找回来最后一条建表规矩：**单表超过 500 万行或 2GB，才推荐分库分表**。如果预计三年后数据量根本到不了这个级别，千万别在建表时提前分——分布式事务、跨库查询、主键方案这些复杂度，不是你现在背得动的。
>**可能有人会问：表才 100 万行，要不要现在就分库分表？**
不用。规范写的是"超过 500 万行或 2GB 才推荐"，按你三年后的增长预估来算。提前分库分表，等于用未来的复杂度惩罚现在的自己，多数项目根本撑不到那个量级。

## 二、索引规约：索引不是越多越好，也不是越少越好

**MySQL 索引优化最常见的两个误区：一是索引宁滥勿缺，二是吝啬到该建的索引不建。** 我的经验是：索引的关键不是数量，而是它能不能被查询真正用到——建了用不上的索引，纯属浪费空间还拖慢写入。
先记死一条硬规：**业务上具备唯一性的字段，哪怕是组合字段，也必须建唯一索引。** 别觉得应用层校验够了就省，墨菲定律保证：只要没有唯一索引，并发场景下脏数据一定会来。至于"唯一索引影响插入速度"，那点损耗可以忽略不计。
几条索引铁律一起给：
1）超过三个表禁止 join；join 的字段类型必须绝对一致，且关联字段必须有索引。
2）varchar 字段建索引必须指定长度，没必要对全字段建。一般长度 20 的索引，区分度能到 90% 以上，可以用 `count(distinct left(列名, 长度)) / count(*)` 算区分度。
3）页面搜索严禁左模糊或全模糊（`%关键字`、`%关键字%`）。索引文件是 B-Tree，最左前缀匹配，左边不确定就用不上索引——这种查询直接走搜索引擎。
4）建组合索引，区分度最高的放最左边；但如果同时有等号和范围条件，等号条件的列要前置。比如 `WHERE c > ? AND d = ?`，即使 c 区分度更高，也要建 `idx_d_c` 而不是 `idx_c_d`。
接下来是我摔得最惨的坑——**隐式转换**。
**隐式转换**：SQL 里字段类型和传入值类型不一致时，MySQL 自动把类型转换后再比较。这个转换过程会导致索引失效，让查询从索引查找退化成全表扫描。
开篇那条 8 秒慢查询就是这么来的：`status` 是 varchar，代码里传 int，隐式转换一发，索引就废了。`EXPLAIN` 的 type 直接变成 `ALL`，全表扫描。
![image](https://developer.qcloudimg.com/http-save/yehe-12591818/76471a72ea38f3e66fa780aeeb060cd6.webp)排查慢查询先看 `EXPLAIN`，type 列从好到差有明确的层级，我画成了这张图——type 至少要 range，ref 更好，const 最理想，看到 `ALL` 基本就是索引没用上：
![EXPLAIN 的 type 优劣层级：const、ref、range、index、ALL，MySQL 开发规范慢查询定位关键](https://developer.qcloudimg.com/http-save/yehe-12591818/4de5751f5a78d7f28d6a175ab702e2eb.png)EXPLAIN 的 type 优劣层级：const、ref、range、index、ALL，MySQL 开发规范慢查询定位关键如果看到 `ALL`，优先怀疑是不是字段类型不一致、是不是没建索引。
然后说**覆盖索引**——这是 MySQL 索引优化里性价比最高的一招。
**覆盖索引（Covering Index）**：查询所需字段全部包含在索引里的情况，直接读索引就够，不用再回主表取整行。相当于查书的目录就能回答"第 11 章是什么标题"，没必要翻到那页。
判断方法：`EXPLAIN` 的 Extra 列出现 `Using index`，就是覆盖索引生效了。看这张对比图，同样是命中索引，走不走覆盖索引差一次回表：
![覆盖索引直接返回结果 vs 回表取整行数据，MySQL 开发规范索引优化关键对比](https://developer.qcloudimg.com/http-save/yehe-12591818/2af7124db752541d16628a69ed1c812f.png)覆盖索引直接返回结果 vs 回表取整行数据，MySQL 开发规范索引优化关键对比如果查询的字段在索引里查不全，会先通过索引定位主键，再回主表取整行——这就是**回表**。回表多一次 IO，数据量大时性能差距非常明显。所以写 SELECT 别上来就 `*`，只取需要的列，往往就能让查询变成覆盖索引。
## 三、SQL 语句：count、sum、NULL 三座山

**SQL 规范里最容易翻车的不是复杂语法，是 count、sum、NULL 这三个看着简单的东西。** 每一条都对应过我线上见过的真实事故。
第一座山是 count。**统计行数必须用 `count(*)`，不要用 `count(列名)` 或 `count(常量)`。** `count(*)` 统计所有行，包括 NULL；`count(列名)` 会跳过该列为 NULL 的行，语义就不对了。`count(distinct 列)` 则是去重统计非 NULL 值。
第二座山是 sum 的 NPE。**当某一列全是 NULL 时，`sum(col)` 返回 NULL 而不是 0。** 拿这个结果直接做运算，Java 侧空指针报错是轻的，业务数据算错才是要命的。规范写法是加一层兜底：
```

    
    
    
  --&nbsp;反例：列全为&nbsp;NULL&nbsp;时，SUM&nbsp;返回&nbsp;NULL
SELECT&nbsp;SUM(amount)&nbsp;FROM&nbsp;orders&nbsp;WHERE&nbsp;status&nbsp;=&nbsp;'PAID';

--&nbsp;正例：用&nbsp;IFNULL&nbsp;兜底
SELECT&nbsp;IFNULL(SUM(amount),&nbsp;0)&nbsp;FROM&nbsp;orders&nbsp;WHERE&nbsp;status&nbsp;=&nbsp;'PAID';
```第三座山是 NULL 判断。**NULL 与任何值直接比较结果都是 NULL**，`NULL = NULL` 不返回 true，`NULL <> 1` 也不返回 false——它们都返回 NULL，而 NULL 在 WHERE 里会被当成假。判断空值请用 `ISNULL()` 或 `IS NULL`，别用 `=`。
此外两个"禁用"要记牢：**外键与级联必须禁用**，一切外键概念在应用层解决——外键影响插入速度，级联更新是强阻塞，分布式高并发场景更是更新风暴的温床；**存储过程必须禁用**，难以调试、难以扩展、没有移植性。
>**可能有人会问：禁用外键，那数据一致性谁来保证？**
应用层事务来保证。`student` 表删了学生，删除 `score` 表关联记录的逻辑放在同一个事务里，由代码控制顺序。单机低并发时外键省事，但上了分布式，外键的强阻塞就是性能杀手，所以规范宁可让应用层多写两行。

还有一条运维铁律：**数据订正（尤其删改）之前，必须先 SELECT 确认，再执行更新。** 我见过不止一次"UPDATE 忘了带 WHERE，一张表数据全没了"的事故，先查一遍能救你一命。
## 四、ORM 映射：MyBatis 里藏着的隐性炸弹

**ORM 层最大的隐患不是性能，是 SQL 注入和字段乱映射。** 前两章把 SQL 写对，这一章把映射写对，才算真正闭环。
几条强制项：
1）**一律不用 `*` 查字段**，需要哪些列就明确写哪些。`*` 增加解析成本、增删字段容易和 resultMap 对不上、text 大字段白白增加网络消耗——三宗罪，一个都别碰。
2）**参数一律用 `#{}`，禁用 `${}`**。`#{}` 走预编译防注入，`${}` 是字符串拼接，用户输入直接拼进 SQL，等于给攻击者递刀。
3）**更新记录必须同步更新 `update_time` 字段**，否则数据变更时间和记录对不上，排障无从下手。
4）**不要写大而全的更新接口**。传个 POJO 进来，不管有没有变化都 `update set 所有字段`，三个问题：容易误改、效率低、白白增加 binlog 存储。只更新真正变化的字段。
5）多表查询的列，**必须加表别名限定**（`t1.name`）。我同事就栽过：某表新增了一个 `name` 字段，预发布变更一跑，线上直接抛 `Column 'name' in field list is ambiguous`，列名歧义，排查了半天。
![image](https://developer.qcloudimg.com/http-save/yehe-12591818/9be397510b4fb31d38c1b7495704fb7d.webp)

----
把四块串起来看，其实就一句话：**MySQL 开发规范里几乎没有一条是锦上添花，每一条背后都对应过一次线上事故。** 命名乱起、类型乱用、索引乱建、NULL 裸奔——这些"小问题"在数据量上来之后，都会变成你凌晨三点爬起来救火的理由。
**建表（MySQL 建表规范）、索引（MySQL 索引优化）、SQL、ORM 四块**都能在这篇里找到对应的坑。后续我打算再写一篇 `EXPLAIN` 实战解读，把慢查询定位讲透，感兴趣的可以在评论区告诉我。


----
我是晚安code，持续分享编程干货。觉得有用的话记得点赞收藏和关注~也欢迎在评论区聊聊：你在 MySQL 开发规范上踩过最疼的一个坑是什么？

大家好，我是晚安code。假设一个场景一条慢查询，单表两千万行，WHERE status = ? 一条简单过滤跑了 8 秒。EXPLAIN 一看 type 是 ALL，全表扫描。原因说出来你可能不信：status 字段是 varchar，代码里传了个 int，MySQL 一隐式转换，索引直接作废。这种坑，MySQL 开发规范里几乎每条都在提醒你。这种坑，我把建表、索引、SQL、ORM 四块最要命的强制项整理成这份清单（2026 年 8 月整理，以 MySQL 8.0 为基线）。MySQL 开发规范里最值钱的一条经验是：表一旦上线，字段名和类型基本就改不动了，所以每一行 DDL 都值得你认真写。先点个收藏，咱们一条条过。

MySQL 开发规范清单：建表、索引、SQL、ORM 四块一次讲透

MySQL 开发规范怎么落地？本文把阿里 Java 手册里建表、索引、SQL、ORM 四块的硬性规约拆成一份清单，每条配反例和血泪经验，收藏这一篇就够用了。

数据库

后端

编程语言

MySQL开发规范核心要点：建表命名全小写单数、布尔用is_xxx、必备id和时间字段；索引需建唯一约束、组合索引区分度最高前置、避免隐式转换致索引失效；SQL用count(*)统计、sum加IFNULL兜底、NULL用IS NULL判断；ORM禁用*和${}、参数用#{}防注入。每项规范背后都是线上事故教训，收藏这份清单避免踩坑。

数据一致性

Windows

MySQL

Linux

Java

腾讯云数据库特惠，新用户首单0.5折起


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

MySQL开发规范核心要点：建表命名全小写单数、布尔用is_xxx、必备id和时间字段；索引需建唯一约束、组合索引区分度最高前置、避免隐式转换致索引失效；SQL用count(*)统计、sum加IFNULL兜底、NULL用IS NULL判断；ORM禁用*和${}、参数用#{}防注入。每项规范背后都是线上事故教训，收藏这份...

MySQL 开发规范清单：建表、索引、SQL、ORM 四块一次讲透-腾讯云开发者社区-腾讯云

MySQL 开发规范清单：建表、索引、SQL、ORM 四块一次讲透

MySQL 开发规范清单：建表、索引、SQL、ORM 四块一次讲透

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐