MySQL表操作全攻略：从建表设计到性能与锁排查

最近看到一串 MySQL 相关的热搜词，不少人在搜“mysql中int+5”、“mysql的or能去重吗”、“mysql自动忽略大小写”这类问题。说实话，这些问题单独拿出来都很简单，但连在一起看就很有意思——它们背后指向的都是同一个根基：对表本身的理解。表是 MySQL 里真正的核心容器，库只是目录，索引、约束、数据最终都落在表上。建表、看表、改表、删表，再加上对表内数据的增删改查，这些“基本操作”如果只是背语法，遇到实际问题一样会翻车。

这篇文章我就用一套“学生选课成绩”的模拟场景，把 MySQL 表的基本操作完整走一遍。不光是 CREATE TABLE 和 ALTER TABLE 的语法，还会解释每一步为什么这么选、哪些细节容易踩坑，顺便把热搜里那些零散问题都串起来。适合刚学完 SQL 基础、准备正经做数据建模的初学者，也适合写过一段时间 SQL 但没系统整理过表设计细节的同学。

1. 建表之前：先想清楚业务实体，再动手写 CREATE TABLE

很多新人最大的问题是拿到需求就敲键盘，表结构下意识列几个字段就完事。但表是业务的投影，字段类型、约束、索引设计得不好，后面每一次查询都在为当时的草率买单。所以建表之前，先把业务里有哪些“实体”、实体之间什么关系搞清楚，这一步比 SQL 语法重要十倍。

1.1 从一张学生成绩表的需求说起

假设要做一个最简单的学生选课成绩库，需求大概是这样：学校有学生，学生有学号、姓名、性别、出生日期、入学日期；学校开设课程，课程有课程号、课程名、学分、任课教师；学生选了某门课之后，会产生一个成绩，还要记录考试日期。

如果只图省事，很可能会建一张大宽表，把所有东西塞进去：

sql复制CREATE TABLE student_score (
  student_no  VARCHAR(20),
  student_name VARCHAR(64),
  course_no   VARCHAR(20),
  course_name VARCHAR(100),
  credit      DECIMAL(3,1),
  teacher     VARCHAR(64),
  score       DECIMAL(5,2),
  exam_date   DATE
);

这种表在 demo 阶段没毛病，查起来甚至很爽，一个 SELECT 什么都出来了。但它经不起真实业务推敲：一个学生选了 10 门课，学生姓名、性别这些信息就要在这张表里重复出现 10 次，这就是数据冗余；哪天学生改了个名字，你得 UPDATE 这张表的每一行，漏掉一行就出现数据不一致。于是就有了关系数据库最基本的设计思路：把不同类型的实体拆成不同的表，用主键唯一标识一行，用外键或逻辑关联把表连起来。

同样的需求拆成三张表，就会清爽很多：

• student：学生基本信息，一行代表一个学生。
• course：课程基本信息，一行代表一门课程。
• score：学生与课程的成绩关系表，一行代表“某个学生考了某门课的成绩”。

这就是学生选课场景里最经典的模型，也是热搜里“学生课程成绩信息实体表设计”那个词背后真正的答案。表不是越少越好，也不是越多越好，而是每一张表都只表达一个清晰的主题。

1.2 存储引擎与字符集：一开始选错，后面迁移很痛苦

表结构设计里有两个最容易被忽略的全局选择，一个是存储引擎，一个是字符集。

存储引擎强烈建议用 InnoDB，理由很实际：支持事务、支持行级锁、支持崩溃恢复。MyISAM 在很多老教程里还会出现，但它的表级锁在并发写入场景下非常吃亏，而且不支持事务，数据一致性没有保障。现在 MySQL 8.0 里 InnoDB 已经是默认引擎，但建表时明确写出来是个好习惯，至少别人看你的建表语句时不会被当前环境的默认配置误导。

字符集这一块，我见过太多历史包袱。早年建库用 utf8，结果插入 emoji 或者一些生僻字直接报错，因为 MySQL 的 utf8 最多只支持 3 字节，真正的四字节字符存不进去。正确选择是 utf8mb4，它才是完整的 UTF-8 实现。如果是 MySQL 8.0，排序规则可以直接用默认的 utf8mb4_0900_ai_ci，这个 collation 支持 Unicode 9.0，比较规则也比较合理；如果是 5.7 或更早，建议用 utf8mb4_general_ci 或 utf8mb4_unicode_ci。

这里的 _ci 后缀代表 case insensitive，也就是比较时忽略大小写。这会导致一个很多人困惑的现象：为什么 WHERE name = 'zhang' 能查出 ZHANG？因为 utf8mb4_0900_ai_ci 本身就不区分大小写。如果你需要严格区分，就得用 utf8mb4_bin 或 utf8mb4_0900_as_cs 这类排序规则。这就是热搜里“mysql自动忽略大小写”的根源，不是 MySQL 抽风，是你在建库建表的时候选了个不区分大小写的 collation。

2. CREATE TABLE 落地：字段类型与约束决定表的性能上限

设计完模型，接下来就是把模型翻译成 DDL。这一阶段最常见的误区，集中在数值类型、字符类型和约束三个方面。

2.1 int(5) 到底是什么意思：一个热搜词的典型误解

热搜里有“mysql中int+5”，我猜很多人想问的是 int(5) 这个写法。先说结论：int(5) 里的 5 不是存储长度限制，也不会限制你存多大的数字。

MySQL 整数类型占用的字节数是固定的，INT 永远占 4 字节，取值范围是 -2147483648 到 2147483647，无符号的话是 0 到 4294967295。括号里的数字只是“显示宽度”，主要配合 ZEROFILL 使用。比如 INT(5) ZEROFILL 存 42，查询出来显示 00042，但存储的还是整数 42。这个显示宽度在 modern MySQL 8.0 里已经逐渐被废弃，新代码里我建议直接写 INT，不要写 INT(5)。

对应到热搜“int+5”还有一个方向理解：更新语句 UPDATE student SET age = age + 5 WHERE id = 1，这种情况下要考虑的是整数溢出。比如一个 TINYINT 字段最大值 127，你给它加 5 就可能报 Out of range value 错误。所以选择整数类型时，要根据业务数据的量级预留足够余量：状态码用 TINYINT，年龄、数量用 INT，如果可能超过 21 亿，比如评论数、流水号，就要直接上 BIGINT。

我把常用的整数类型列个表，方便你一眼看清边界：

2.2 字符类型与小数精度：VARCHAR、CHAR、DECIMAL 怎么选

字符类型上，最常用的就是 VARCHAR 和 CHAR。VARCHAR 是变长的，存多少用多少，额外加 1 到 2 字节记录长度，适合姓名、邮箱、地址这类长度参差不齐的字段；CHAR 是定长的，适合长度固定且短的字段，比如手机号、MD5 后的哈希值。这里要纠正一个旧观念：VARCHAR 不会因为“预留了 100 个字符”就固定占用 100 个字符的空间，它只按实际内容占空间，所以不用太抠门，但也别一上来就 VARCHAR(5000)——索引是有长度上限的，InnoDB 的单列索引在 utf8mb4 下最大不超过 3072 字节，大字段做索引会非常占空间。

小数类型更需要谨慎。FLOAT 和 DOUBLE 是浮点数，会有精度误差，不适合存钱、成绩等需要精确计算的场景。DECIMAL 才是定点数，底层按字符串存储。比如成绩表里的分数可以用 DECIMAL(5,2)，表示最多 5 位数字，小数点后 2 位，可以存 0 到 999.99。学分用 DECIMAL(3,1)，存 3.0、4.5 这种一位小数。这就是为什么“mysql可以存储整数数值的是”这种问题背后，其实要理解每种类型的能力边界。

时间类型也不能乱用。业务上记录“某个时刻”一般用 DATETIME 或 TIMESTAMP。DATETIME 不依赖时区，适合存创建时间这种固定时间点；TIMESTAMP 会随数据库时区转换，而且范围只到 2038 年，新业务里我更推荐 DATETIME。记录“某一天”就用 DATE，比如生日、入学日期、考试日期，占用空间更小，语义也更准确。

2.3 主键、自增、唯一约束：三个必须想清楚的决策

主键是表设计里最核心的决策。InnoDB 是聚簇索引组织表，数据行物理上按主键顺序存放，所以主键最好是单调递增的。用自增 INT 或 BIGINT 做主键是默认稳妥方案。用 UUID 或业务字符串做主键不是不行，但随机字符串会导致页分裂、索引碎片化，写入性能会有明显下降。除非有分库分表或数据合并需求，否则我建议保留一个自增代理主键，业务编号（如学号、课程号）用唯一索引去约束。

自增主键有个经典坑，就是删除最大 id 后再插入，自增值不会回退。比如你有一张表最大 id 是 100，删掉 100 这条记录，再插入新数据，新的 id 很可能是 101 而不是 100。这是正常的，自增值一旦使用就不会因为删除而回退，别写成代码里假设 id 必须连续。MySQL 8.0 之前的版本还有一个“自增回溯”问题：事务回滚后自增值可能被消耗掉，导致 id 不连续。这都属于正常现象，不要试图去“修复”它。

UNIQUE 唯一约束用来保证业务上不允许重复的字段。比如学生表的学号，课程表的课程号，成绩表的 (student_id, course_id) 联合唯一——这样能保证同一个学生对同一门课只可能有一条成绩记录。

至于外键，教程里特别喜欢讲，但在真实互联网业务里我建议默认不用。外键会把数据一致性压力放在数据库层，在高并发分布式环境下会引发锁竞争、扩容困难、删除父表数据时阻塞一大堆子表操作。一致性交给应用层去保证，数据库只负责存储和索引，反而是更常见的工业实践。学习阶段理解外键概念没问题，正式生产环境前要慎重。

3. 完整实操：从零构建学生选课成绩库

模型想清楚、类型选明白，这一步就可以写正式建表语句了。我用 MySQL 8.0 默认配置来演示，库名就叫 school。

3.1 三张表的建表 SQL

先建学生表：

sql复制CREATE TABLE student (
  id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '内部主键',
  student_no VARCHAR(20) NOT NULL COMMENT '学号',
  name VARCHAR(64) NOT NULL COMMENT '姓名',
  gender TINYINT NOT NULL DEFAULT 0 COMMENT '性别: 0未知, 1男, 2女',
  birth_date DATE DEFAULT NULL COMMENT '出生日期',
  enroll_date DATE NOT NULL COMMENT '入学日期',
  status TINYINT NOT NULL DEFAULT 1 COMMENT '状态: 1在读, 0离校',
  created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (id),
  UNIQUE KEY uk_student_no (student_no),
  KEY idx_enroll_date (enroll_date)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='学生信息表';

这里几个细节值得说明。INT UNSIGNED 让主键只能存非负数，范围扩大一倍，4 字节能存到 42 亿，对小表来说完全够用。字段都加了 COMMENT，在团队协作里这是最低成本的文档。created_at 和 updated_at 的默认值处理是 InnoDB 的常用手法，DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP 表示插入时自动记录当前时间，更新这行数据时自动刷新为最新时间。

然后建课程表：

sql复制CREATE TABLE course (
  id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '内部主键',
  course_no VARCHAR(20) NOT NULL COMMENT '课程编号',
  course_name VARCHAR(100) NOT NULL COMMENT '课程名称',
  credit DECIMAL(3,1) NOT NULL DEFAULT 0.0 COMMENT '学分',
  teacher_name VARCHAR(64) DEFAULT NULL COMMENT '任课教师',
  created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  PRIMARY KEY (id),
  UNIQUE KEY uk_course_no (course_no)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='课程表';

最后建成绩表，它是 student 和 course 的关联表：

sql复制CREATE TABLE score (
  id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '内部主键',
  student_id INT UNSIGNED NOT NULL COMMENT '学生id, 关联student.id',
  course_id INT UNSIGNED NOT NULL COMMENT '课程id, 关联course.id',
  score DECIMAL(5,2) NOT NULL COMMENT '考试成绩',
  exam_date DATE NOT NULL COMMENT '考试日期',
  created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (id),
  UNIQUE KEY uk_student_course (student_id, course_id),
  KEY idx_course_id (course_id),
  CONSTRAINT fk_score_student FOREIGN KEY (student_id) REFERENCES student (id),
  CONSTRAINT fk_score_course FOREIGN KEY (course_id) REFERENCES course (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='成绩表';

我在这里特意保留了外键，是为了演示一对一、一对多关系下约束的作用。但正如前面所说，实际生产环境中外键往往会被去掉，保留的只是普通索引 KEY idx_course_id 和业务代码层面的关联逻辑。

值得一提的是，score 表主键用了 BIGINT，因为成绩流水是持续增长的数据，INT 在极端场景下不够用。这也是选型时要提前想好的事：基础表主键 INT 够用，流水表主键直接上 BIGINT，别等业务跑了两三年再去改表，那真是劳民伤财。

3.2 查看表结构：DESC 与 SHOW CREATE TABLE 各有分工

表建好之后，怎么确认结构对不对？最常用的两个命令是 DESC 和 SHOW CREATE TABLE。

sql复制DESC student;

DESC 会把表的字段、类型、是否为空、默认值、主键等信息以表格形式列出来，适合快速浏览。但它不会展示索引、外键、字符集、注释这些细节。要想完整看到当初建表语句的每一个参数，用：

sql复制SHOW CREATE TABLE student\G

它会把 MySQL 内部保存的完整建表语句原样输出，包括引擎、字符集、注释、约束、索引定义。我排查问题时的习惯是先 SHOW CREATE TABLE 看全貌，再用 DESC 对照具体的字段类型。EXPLAIN 做查询分析时也经常需要看表结构，两者配合能更快定位问题。

如果想把表结构导出成 ER 图，工具层面 Navicat、MySQL Workbench 这类客户端都提供逆向工程功能，可以从现库生成 ER 图。但如果你依赖命令行，SHOW CREATE TABLE 配合元数据表 information_schema.COLUMNS 就足够用来做结构比对和文档生成。

3.3 插入初始数据并做一次简单查询验证

表结构没报错只是第一步，通常我会插入几条测试数据，验证约束是否按预期工作，也方便后续演示增删改查。

sql复制INSERT INTO student (student_no, name, gender, birth_date, enroll_date)
VALUES
('2024001', '张伟', 1, '2005-03-12', '2024-09-01'),
('2024002', '李娜', 2, '2006-07-24', '2024-09-01'),
('2024003', '王强', 1, '2005-11-02', '2024-09-01');

INSERT INTO course (course_no, course_name, credit, teacher_name)
VALUES
('CS101', '数据库原理', 4.0, '刘老师'),
('CS102', '操作系统', 3.5, '陈老师'),
('MA101', '高等数学', 5.0, '赵老师');

INSERT INTO score (student_id, course_id, score, exam_date)
VALUES
(1, 1, 88.50, '2025-01-10'),
(1, 3, 92.00, '2025-01-15'),
(2, 1, 75.00, '2025-01-10'),
(3, 2, 86.00, '2025-01-12');

注意插入顺序：要先有学生、课程，才能插入成绩，不然外键约束会直接报错。这个顺序在演示外键的语义时非常直观——数据库替你把了最后一道关。

快速查询一下每个学生的选课和成绩：

sql复制SELECT s.student_no, s.name, c.course_name, sc.score
FROM student s
JOIN score sc ON sc.student_id = s.id
JOIN course c ON c.id = sc.course_id
ORDER BY s.student_no, c.course_name;

看到结果正常返回，说明表结构、外键、索引基本没有语法问题，可以继续往下进行维护操作的学习。

4. 修改表结构：ALTER TABLE 的生产环境锁与坑

表在运行期难免需要调整：加字段、加索引、改字段长度。新手最容易在 ALTER TABLE 上掉以轻心，因为测试环境小表几十毫秒就改完了，线上大表可能直接把人拖垮。

4.1 常见 ALTER TABLE 操作速查

给已有表添加字段：

sql复制ALTER TABLE student
ADD COLUMN email VARCHAR(128) NULL COMMENT '邮箱' AFTER name;

AFTER name 表示把新字段放到 name 字段后面。生产环境其实不用太执着于字段顺序，逻辑上可以用视图来控制展示顺序，但小项目里 AFTER 能让表结构读起来更舒服。

修改字段类型或默认值：

sql复制ALTER TABLE student
MODIFY COLUMN email VARCHAR(200) NOT NULL DEFAULT '' COMMENT '邮箱';

修改字段名：

sql复制ALTER TABLE student
CHANGE COLUMN email contact_email VARCHAR(128) NULL COMMENT '联系邮箱';

删除字段：

sql复制ALTER TABLE student
DROP COLUMN contact_email;

添加和删除索引：

sql复制ALTER TABLE student ADD INDEX idx_name (name);
ALTER TABLE student DROP INDEX idx_name;

这些操作在测试表上随便跑，但不要忘记：ALTER TABLE 不只是一条 DDL，它在执行过程中会持有元数据锁并可能重建表。

4.2 大表修改结构的真实风险：MDL 与锁等待

MySQL 的 DDL 一直在进化。MySQL 8.0 里，某些操作已经支持 INSTANT 算法，比如直接在表尾追加字段，只需要修改元数据，瞬间完成；另一些操作需要 INPLACE，比如添加索引，虽然不复制整表，但可能需要在原地重建；更古老的 COPY 算法则会锁住表并复制全量数据，耗费大量磁盘空间和时间。

即使算法本身很快，还有一个隐藏的锁：元数据锁。当你执行 ALTER TABLE 时，MySQL 需要拿到表的元数据锁。如果此时有一个长事务或长时间未提交的查询还占用着这张表，DDL 就会卡在 Waiting for table metadata lock 状态。更麻烦的是，DDL 一旦开始排队，后续所有针对这张表的查询和写入都会被阻塞，连 SELECT 都进不来。这是生产环境里最典型的“一条 ALTER 卡死整个业务”的场景。

所以我在执行重要 DDL 前，一定会先检查有没有未结束的事务：

sql复制SELECT * FROM information_schema.INNODB_TRX\G
SELECT * FROM performance_schema.metadata_locks\G

如果发现有长事务占用，需要先确认是正常业务还是僵尸连接，再决定是否等待或终止。终止长时间挂起的事务可以用：

sql复制KILL 1234;

这里的 1234 是事务所在连接的 processlist id，执行前一定要确认号，别手滑把正常业务连接杀了。

在 MySQL 8.0 上，添加字段这类操作可以显式指定算法和锁级别，比如加索引时用：

sql复制ALTER TABLE score ADD INDEX idx_exam_date (exam_date), ALGORITHM=INPLACE, LOCK=NONE;

LOCK=NONE 是在请求“执行 DDL 期间允许并发读写”，但能不能实现取决于具体操作类型。如果拿不到足够的锁权限，MySQL 会报错或自动降级，所以不要以为写了 LOCK=NONE 就一定不阻塞。

4.3 大表改结构的终极方案：在线变更工具

当表数据量达到几千万甚至上亿行时，即使 INPLACE 操作也可能耗费很长时间，造成主从延迟、磁盘 IO 飙升。更稳妥的做法是用在线表结构变更工具。业界最常用的两套是 Percona 的 pt-online-schema-change 和 GitHub 的 gh-ost。它们的基本逻辑都是创建一张影子表，通过触发器或 binlog 同步增量数据，最后原子切换表名。这样在线 DDL 期间，业务读写基本不受影响。

使用这类工具前要注意：它要求表必须有主键，因为增量同步依赖主键定位行；表上不能有外键，否则切换时会非常痛苦。这套工具在老项目里几乎是 DBA 必备技能，如果你只是维护小表，理解存在这样的方案即可，真到需要的时候再按官方文档仔细操作。

5. 表内数据的增删改查：最容易翻车的三个操作场景

表结构稳定之后，大部分日常工作是操作表里的数据。INSERT、UPDATE、DELETE 看起来简单，实际最容易出事。

5.1 INSERT 的隐式陷阱：字段清单与 NULL 语义

INSERT 最基本的原则就是永远写字段清单：

sql复制INSERT INTO student (student_no, name, gender, birth_date, enroll_date)
VALUES ('2024004', '赵敏', 2, '2005-09-18', '2024-09-01');

不写字段清单的写法：

sql复制INSERT INTO student VALUES (NULL, '2024004', '赵敏', 2, '2005-09-18', '2024-09-01', 1, NOW(), NOW());

这种写法看着省事，但它要求 VALUES 里的顺序和数量必须和表结构完全一致。一旦表加过字段、调整过顺序，这段 SQL 就可能把数据插到错误的列里，或者直接报 Column count doesn't match value count。而且这种语句可读性很差，别人维护时根本不知道每个值对应哪个字段。

另一个需要警惕的是 NULL 的语义。NULL 和空字符串 '' 是两回事，NULL 代表“未知”，'' 代表“值为空字符串”。做条件判断时，WHERE email = '' 查不到 email IS NULL 的记录；WHERE email IS NULL 也查不到空字符串。这个差异在聚合函数上更明显：COUNT(email) 只会统计非 NULL 的行，COUNT(*) 统计所有行。如果业务上要求“没有邮箱就是空字符串”，建表时可以直接设定 NOT NULL DEFAULT ''，尽量避免 NULL 字段带来的三值逻辑困扰。

5.2 UPDATE 和 DELETE 的边界：为什么基本操作也容易酿成事故

UPDATE 不写 WHERE，全表更新；DELETE 不写 WHERE，全表删除。这不是段子，是每天都在发生的真实事故。

sql复制UPDATE student SET status = 0 WHERE student_no = '2024001';
DELETE FROM score WHERE student_id = 3 AND course_id = 2;

要删除某条记录前，建议先 SELECT 确认范围：

sql复制SELECT * FROM score WHERE student_id = 3 AND course_id = 2;

确认无误后再执行 DELETE，并且观察影响行数是否和预期一致。一个非常实用的小技巧是开启 sql_safe_updates：

sql复制SET SESSION sql_safe_updates = 1;

这个参数打开后，MySQL 会拒绝执行不带 WHERE 且没有 LIMIT 的 UPDATE 或 DELETE。它会逼你在写更新删除语句时至少加一个条件，能避免大部分手滑。虽然测试环境用它可能会觉得碍事，但生产连接上开启它，可能是性价比最高的安全措施。

事务也很重要。多行更新或删除时，用事务把操作包起来：

sql复制START TRANSACTION;
UPDATE score SET score = score + 5 WHERE student_id = 1;
-- 确认无误再提交
COMMIT;
-- 如果发现不对
-- ROLLBACK;

不要小看这条习惯。很多线上事故本来只要一条 ROLLBACK 就能救回来，就是因为没有主动开启事务，每一条语句自动提交，等到发现问题时数据已经落盘了。

5.3 DELETE 和 TRUNCATE、DROP 的本质差别

这三个都能让数据消失，但原理完全不同。

DELETE 是 DML，逐行删除，可以通过 WHERE 限定范围，并且删除前可以在事务里回滚。它会记录 binlog，产生大量 undo 日志，删除大表时速度慢，还可能造成主从延迟。

TRUNCATE TABLE 是 DDL，直接把整张表的存储空间重置，速度极快，但它不能加 WHERE，也不能回滚，并且会重置自增计数。适合清空一张临时表并希望 id 从 1 重新开始。

DROP TABLE 更彻底，整张表结构连同数据和索引一起删除。执行之后如果想反悔，只能靠备份恢复。

一个简单的决策梯度是这样的：只想删部分行，用 DELETE；想清空整张表但保留表结构，而且不 care 自增，用 TRUNCATE；想连同表结构一起消失，用 DROP。我实际工作中对线上表的 DROP 极其谨慎，因为 DROP 之后不只是数据没了，相关权限、依赖关系、定时任务都可能受影响。删表前至少看一眼 information_schema.KEY_COLUMN_USAGE，确定没有其他表的外键指向它。

6. 排序、去重、大小写：从几个冷门热搜看基础查询细节

MySQL 表的基本操作一定绕不开 SELECT，但这里不准备复述所有查询语法，只挑热搜词里最有代表性、也最容易搞混的几个点来拆。

6.1 “mysql的or能去重吗”：问题背后的 SQL 逻辑误判

有人问“or 能去重吗”，大概率是遇到用 OR 连接条件时查出了重复数据，不知道是不是 OR 导致的。真相是：OR 本身不会产生重复行，重复数据通常来自多表连接时一对多关系的膨胀，或者查询本身就存在重复记录。

看看这个例子，用 OR 查两个课程的成绩：

sql复制SELECT student_id, course_id, score
FROM score
WHERE course_id = 1 OR course_id = 3
ORDER BY student_id;

如果同一个学生只考了一次课程 1、一次课程 3，这条语句不会有重复。但如果你把这张表 JOIN 到其他会产生多行匹配的表上，行的数量就会被放大，这时去重需要用 DISTINCT，而不是指望条件本身帮你收敛。

把 OR 改成 IN 往往更清晰：

sql复制SELECT student_id, course_id, score
FROM score
WHERE course_id IN (1, 3)
ORDER BY student_id;

IN 在语义上等价，但可读性更好，也更利于 MySQL 优化器在某些场景下走索引优化。需要真正去重时再看下一节。

6.2 DISTINCT 去重与 GROUP BY 的分工

DISTINCT 是用来去除查询结果中重复行的：

sql复制SELECT DISTINCT course_id FROM score;

这能查出有成绩记录的课程 id。但 DISTINCT 有一个限制：它作用于 SELECT 后所有列的联合组合。如果写 SELECT DISTINCT student_id, course_id FROM score;，它去重的是 (student_id, course_id) 这个组合，而不是单独去重 student_id。

如果需求是“统计每个学生选了几门课”，更适合用 GROUP BY 加聚合函数：

sql复制SELECT student_id, COUNT(*) AS course_count
FROM score
GROUP BY student_id
ORDER BY course_count DESC;

简单场景下 DISTINCT 相当于 GROUP BY 去掉聚合列，但 GROUP BY 可以做更细粒度的分组统计，两者不能完全划等号。还有一个容易错的点：COUNT(DISTINCT course_id) 可以统计去重后的数量，直接写出如下写法：

sql复制SELECT COUNT(DISTINCT course_id) FROM score;

如果你在一条 SQL 里既要分组明细，又要去重，思考清楚数据粒度后用 GROUP BY 通常更顺手。

6.3 表名和列名的大小写策略：lower_case_table_names 要统一

热搜里“mysql自动忽略大小写”还可能指表名、列名的大小写策略。MySQL 对表名的处理受 lower_case_table_names 参数控制。这个参数在 Linux 上默认是 0，表示表名区分大小写；在 Windows 上默认是 1，表示不区分；macOS 默认是 2，表示存储时保留原样但比较时不区分。跨平台迁移数据库时如果没注意这个差异，经常会出现开发环境跑得好好的，生产环境却报 Table doesn't exist。

更麻烦的是，lower_case_table_names 参数在 MySQL 8.0 里只能在数据库初始化时设置，不能随意修改。如果你接手项目，一定要先确认源库和目标库的这个参数一致再迁移。

列名和字段名在 MySQL 中默认不区分大小写，但为了统一规范，我建议项目里全链路统一：表名小写下划线、字段名小写下划线、SQL 关键字大写。团队协作时，大小写风格不一致的代码 review 起来很痛苦，而且 Linux 环境对表名大小写敏感，一旦 DATABASE 里混入了大小写不同的表，查找 bug 会让你怀疑人生。

6.4 ORDER BY 排序：为什么加了索引还是“Using filesort”

排序也是热搜里的高频词。ORDER BY 看似简单，但很多人用 EXPLAIN 查看执行计划时看到 Using filesort 就慌了，以为出了什么问题。

先明确 filesort 并不是“磁盘文件排序”的代名词，它只是说明 MySQL 需要额外做一次排序操作，这个排序可能在内存的 sort buffer 中完成，也可能需要临时文件。如果数据量不大，filesort 并不可怕；但当数据量很大时，它可能意味着额外的 IO 成本。

sql复制EXPLAIN SELECT student_id, course_id, score FROM score ORDER BY score DESC;

这条语句如果只在 student_id 上有联合索引，ORDER BY score 就无法直接利用索引顺序，Extra 里会出现 Using filesort。解决办法是根据查询模式设计联合索引，比如频繁需要按 course_id 查成绩并排序，可以建 (course_id, score) 联合索引，让排序走索引的有序性。

sql复制ALTER TABLE score ADD INDEX idx_course_score (course_id, score);

但索引不是越多越好，每多一个索引，写入时的维护成本都在增加。看执行计划时，先确认查询是否真的高频、数据量是否大到无法接受 filesort，再决定是否加索引。这也是我坚持让新人先会读 EXPLAIN 再做索引优化，而不是一见面就甩几个“优化建议”的原因。

7. 面向日常维护的元数据查询与锁问题排查

表结构稳定运行、数据正常操作之后，真正的长期工作落在了日常巡检上。这部分内容不算严格意义上的“建表改表”，但和表的基本操作紧密结合。

7.1 从 information_schema 快速定位“异常表”

要知道一个库里有哪些表、每张表大概多少行、占了多大空间，最常见的做法是查 information_schema.TABLES：

sql复制SELECT table_name, table_rows, data_length, index_length,
       create_time, update_time, table_collation
FROM information_schema.TABLES
WHERE table_schema = 'school'
ORDER BY data_length DESC;

这里有一个非常关键的注意点：table_rows 对 InnoDB 表来说只是优化器的估算值，不是精确行数。它来自索引统计信息的采样，可能相差很多。想获取精确行数只能 COUNT(*)，但大表 COUNT(*) 全表扫描很慢。所以如果你只是巡检找趋势，用 table_rows 就够了；如果是要对账，老老实实跑 COUNT(*)。

几个我常用的判断标准：index_length 明显大于 data_length 的表，说明索引建得太冗余；data_free 较大时，表碎片化严重，可以评估 OPTIMIZE TABLE 整理碎片。但 OPTIMIZE TABLE 同样会锁表，要在低峰期执行，或用在线工具。

7.2 表锁和行锁：一条 UPDATE 卡住整个表怎么办

热搜里 “mysql锁表” 出现频率很高。场景一般是：某个同事在客户端打开了事务，执行了 UPDATE 但没提交，甚至直接关掉了客户端窗口但连接还挂在那里。由于 InnoDB 默认是行锁，别的事务更新同一行时就会卡住，表现就是“表锁住了”。

排查锁等待的第一步，是看现在有哪些事务正在执行：

sql复制SELECT * FROM performance_schema.data_lock_waits\G
SELECT * FROM sys.innodb_lock_waits\G

sys.innodb_lock_waits 是比较人性化的视图，会直接告诉你哪个事务阻塞了哪个事务。如果不想安装 sys schema，也可以查：

sql复制SELECT * FROM information_schema.INNODB_TRX\G
SELECT * FROM performance_schema.metadata_locks\G

看 trx_state 是否为 LOCK WAIT，trx_query 是什么 SQL，trx_started 已经跑了多久。如果是僵尸事务，直接通过 processlist id 执行 KILL。

另一个容易忽略的是 DDL 引发的元数据锁，正如第 4.2 节所说，所有与表相关的 DML 也会被堵住。排查时要先区分等待的是行锁还是 MDL，因为处理方式不同：行锁一般是事务未提交导致的，MDL 往往是 DDL 排队后把后续请求全堵住了。

7.3 配合常用函数做表数据统计

日常巡检除了看表结构，还要从表数据里拎出业务指标。MySQL 的常用函数大致分几类：聚合函数（COUNT、SUM、AVG、MAX、MIN）、日期函数（DATE_FORMAT、YEAR、MONTH）、字符串函数（CONCAT、SUBSTRING）、流程控制函数（CASE WHEN）。组合使用时，能完成的统计种类会很丰富。

比如我想知道每门课程的最高分、最低分、平均分和选课人数：

sql复制SELECT c.course_name,
       COUNT(*) AS exam_count,
       ROUND(AVG(sc.score), 2) AS avg_score,
       MAX(sc.score) AS max_score,
       MIN(sc.score) AS min_score
FROM score sc
JOIN course c ON c.id = sc.course_id
GROUP BY c.course_name
ORDER BY avg_score DESC;

想知道成绩分数段的分布，用 CASE WHEN：

sql复制SELECT
  CASE
    WHEN score >= 90 THEN '优秀'
    WHEN score >= 80 THEN '良好'
    WHEN score >= 70 THEN '中等'
    WHEN score >= 60 THEN '及格'
    ELSE '不及格'
  END AS level,
  COUNT(*) AS cnt
FROM score
GROUP BY level
ORDER BY cnt DESC;

这些看似复杂的统计，底子还是表、字段、记录之间的关系。能在 SELECT 里自然把函数和约束用起来，说明你对表的理解已经从“能存数据”上升到了“能分析数据”的层次。

最后再分享一个小习惯。我在写每一张业务表的时候，都会在表名和字段上写清晰的中文 COMMENT，即使当时觉得“这不废话吗”，几个月后回头看也一定会感谢当时的自己。字段命名和注释是表的基本操作中最容易被低估的一环，但它决定了这张表未来两年好不好维护。建表一时爽，维护火葬场的案例，多半都是从注释缺失和字段语义模糊开始的。