MySQL 的表操作，说难不难，说简单也真不简单。很多人天天对着 Navicat 或者命令行敲create table、alter table，觉得自己已经把“表的基本操作”拿捏死了，结果一到线上环境就翻车——不是改表把库锁了十分钟，就是建表时留下了一个后期根本没法用的结构。这篇文章不是那种从入门到放弃的照本宣科，我会从一个实际干活的视角，把 MySQL 表的创建、结构修改、索引管理、数据操作这些基础环节里真正值得注意的细节全部掏出来讲一遍，适合刚学会select * from xxx的新手，也适合那些“会操作但没想过为什么”的进阶用户。
1. 建表之前，先把这些想清楚
很多人建表都是鼠标一点“新建表”，然后噼里啪啦敲几个字段就完事了。但表一旦上线，结构想再改就得付出代价，所以建表时的每一个选择，背后都对应着一个长期成本。
1.1 存储引擎不是只有 InnoDB 和 MyISAM 这两个选项
现在默认就是 InnoDB，绝大多数情况下你不需要换，但你要想明白为什么。
InnoDB 是事务型存储引擎，支持行级锁、外键、崩溃恢复，这些特性直接决定了你的业务数据安全性和并发能力。MyISAM 当年流行是因为它读快、索引结构简单，但它不支持事务，崩溃后表容易损坏，而且锁粒度是表级，写并发一高就完蛋。如果你现在还在用 MyISAM，建议尽早迁到 InnoDB，除非你的场景极其特殊（比如纯读的归档表、对空间占用极度敏感）。
建表时引擎的选择不是随便写个ENGINE=InnoDB就完事，你需要顺带考虑行格式和压缩。InnoDB 的ROW_FORMAT有 Compact、Dynamic、Compressed，MySQL 5.7 以后默认是 Dynamic，这个不用动。但如果你的表里有很多TEXT、BLOB类型的字段，COMPRESSED行格式配合KEY_BLOCK_SIZE参数可以帮你省不少磁盘空间，代价是 CPU 压力会上升。我处理过一张带大文本字段的日志表，改成压缩格式后磁盘占用从 90G 降到 40G，性价比极高，建议大家在归档表上试试。
1.2 字符集和排序规则的坑，踩一次就记住了
建表时最容易被忽略的就是CHARSET和COLLATE。我见过无数项目库表全是utf8mb4_general_ci，也没人觉得有什么问题，直到哪天要按中文拼音排序或者遇到 emoji 存不进去才炸锅。
先说结论：
- 字符集统一用
utf8mb4，这是 MySQL 对 Unicode 支持最完整的字符集，能存表情符号、生僻字。 - 排序规则推荐
utf8mb4_unicode_ci或者utf8mb4_0900_ai_ci（MySQL 8.0+）。general_ci的排序精度不够，遇到某些欧洲语言字符或者特殊字母排序时会不符合预期。 - 库、表、字段三层字符集要全部对齐，否则就会出现“表是 utf8mb4、字段是 latin1”这种奇葩结构，写入中文变问号。
还有一点：表的字符集一旦建好，后期再改是全表扫描重写，数据量大时非常恐怖。所以建表前一定确认项目整体字符集规划，别抱着“先建个表以后再做字符集迁移”的想法，这个“以后”通常遥遥无期，而且真要干的时候代价远比你想象的大。
1.3 字段类型选错，后面全得还债
字段类型的选择是建表环节里最考验功力的地方，也是最容易留下后患的地方。直接说我见过的高频错误：
整数类型。INT就是 4 字节，范围到 21 亿左右，够绝大多数业务用。但如果你存的是状态码、枚举值这种不可能超几百的字段，用TINYINT或者SMALLINT更合适，字段越小，索引树越矮，扫描越省 IO。反之，如果业务有成长为超大型系统的可能（比如订单流水），BIGINT才是稳妥选择，我见过有人用INT存订单号存到 21 亿以后溢出，线上直接报错，那种场景下迁移字段类型极其痛苦。
浮点和定点。FLOAT、DOUBLE是浮点数，有精度损失，存金额、库存这种必须精确的数值绝对不要用。钱要用DECIMAL，比如DECIMAL(10,2)表示最多 8 位整数加 2 位小数。这里的位数选择需要你提前想清楚业务量级，我曾经遇到一张表把金额定义为DECIMAL(8,2)，结果累计金额超过 99 万后直接溢出。提前多留几位，比如DECIMAL(12,2)，不占多少空间但省心。
日期时间。DATETIME和TIMESTAMP是最常见的两个。DATETIME范围大（到 9999 年），不受时区影响，适合业务时间。TIMESTAMP只有 4 字节，但范围到 2038 年，而且跟随数据库时区，如果你处理的是全球用户，TIMESTAMP的自动转换反而是个好功能。一个实用建议：如果你的系统访问量不大、时区问题不复杂，直接用DATETIME，不折腾。给时间字段建索引时也注意，条件里写create_time > '2024-01-01 00:00:00'和写create_time > '2024-01-01'的执行性能可能不一样，后者有时会导致索引失效，细节问题后面展开。
字符串。VARCHAR要指定长度，这个长度是字符数不是字节数，utf8mb4下一个汉字占 4 字节。VARCHAR(255)和VARCHAR(500)在存储上的开销逻辑不同——超过 255 字节后，长度标志位会多占字节，索引前缀的限制也更麻烦。能用VARCHAR(50)解决的别拍脑袋设置成VARCHAR(2000)，因为过长的 varchar 列在临时表排序时会吃掉大量内存。
2. 表结构修改，得懂 Online DDL 的脾气
建表只是第一步，业务迭代后改表才是日常。ALTER TABLE这个操作看着就一句 SQL，但你如果不知道它底层怎么干活，大表上一条ALTER就能把业务打死。MySQL 5.6 之后引入 Online DDL，InnoDB 支持在 DDL 期间允许 DML 操作，但不同操作背后的具体行为差别很大。
2.1 为什么 ALTER 一个大表会锁住线上业务
要理解 ALTER 的风险，你得先明白 MySQL 执行 DDL 的几种策略。最原始的方式是 Copy 算法：MySQL 创建一个临时表，把原表数据一行行拷过去，期间锁住原表不让写。这种方式最安全但最慢，大表上执行会锁表数分钟甚至数小时。MySQL 5.6 之后有了 InnoDB Online DDL，部分操作可以直接在原表上进行，通过日志记录 DDL 期间的并发变更。
但不要天真地以为所有 ALTER 都是在线安全的。比如：
- 添加/删除索引：
ADD INDEX、DROP INDEX是支持的，允许并发 DML，但 DDL 过程中有短暂的表级元数据锁（MDL Lock）。 - 修改列类型：比如
ALTER TABLE t MODIFY COLUMN c BIGINT，这类操作通常需要重建表，即使允许并发读，写入也可能被临时阻塞。 - 修改字符集：需要重建整表数据，动辄几分钟甚至几小时。
- 早期版本对
VARCHAR长度的扩展操作，如果新长度超过 255 字节，可能触发表重建。
在 MySQL 8.0 里，ALTER TABLE的ALGORITHM和LOCK参数给了你更多控制力，可以手动指定ALGORITHM=INPLACE或者ALGORITHM=COPY。但线上操作我强烈建议你通过pt-online-schema-change这类工具来执行大表 DDL，它通过创建新表、同步增量、切换表名的方式实现真正的秒级切换，对业务影响最小。小表（几千、几万行）随便 ALTER，几十万行以上就要谨慎了。
2.2 修改表字段时的常见操作错误
先说一个最经典的 Case。你发现orders表的customer_name字段长度不够了，于是执行：
ALTER TABLE orders MODIFY COLUMN customer_name VARCHAR(200);语句没问题，但如果这张表有 1000 万行，这个过程可能要让业务卡顿。而且，MODIFY COLUMN后面只写了字段类型没写NOT NULL和默认值，MySQL 会把原有的这些属性重置。也就是说，你原本的customer_name varchar(50) NOT NULL DEFAULT ''会变成customer_name varchar(200) NULL，默认值没了，非空约束也没了，这很可能导致业务代码里对这个字段的赋值行为发生细微变化。
正确做法的关键点：
- 修改字段时把完整定义写出来：
ALTER TABLE orders MODIFY COLUMN customer_name VARCHAR(200) NOT NULL DEFAULT '' COMMENT '客户姓名'; - 使用
CHANGE COLUMN可以同时改字段名和类型，但 MySQL 会把旧的字段定义完全替换成新定义，同样要注意带上所有属性。 - 修改多个字段时用逗号分隔合并成一条 SQL，避免多次锁表和元数据操作。
- 删除字段前先确认没有索引依赖它，否则删除字段时 MySQL 会顺带删掉相关索引，如果这个索引还承担着另外的查询路径，那就是事故。
2.3 表名和列名的命名，按规范走能救你一命
MySQL 表名和字段名的大小写敏感性与操作系统相关。Linux 下表名默认是大小写敏感的，Windows 下不是。如果你的开发环境是 Windows，部署环境是 Linux，建了UserInfo表，代码里写select * from userinfo，在 Windows 上能跑，到 Linux 上直接报Table doesn't exist。我曾经接手过一个项目，开发全在 Windows，上线全在 Linux，几乎每周都能看到一次表名大小写错误，这种问题逼着你只能把所有表名改成小写下划线风格，并统一lower_case_table_names=1。建议从第一天就规定：表名、字段名全部小写，单词用下划线分隔，不用任何保留字，不用驼峰。
另一个规范问题是保留字。你完全想不到有多少人会把表名起成order、group、key。这些是 MySQL 的保留字，建表时要用反引号才能兜住，而业务代码里写 SQL 时常常忘记反引号，就报语法错误。字段名也类似，我见过有人建了desc字段，每次select desc from table都要带反引号，麻烦一次，下次就记住了。
3. 索引管理，别让表操作毁在索引上
索引不是建了就完事，它需要你反复验证。MySQL 的索引结构默认是 B+Tree，它的特点是有序、树高可控、支持范围查询。但绝大多数人的索引问题是：建得太少导致查询慢，或者建得太多导致写入慢，更常见的是建了但一点用没有。
3.1 不加思索地给每个字段加索引，是最蠢的做法
我见过一张 11 个字段的表，索引建了 9 个。每次插入一条记录，要同时维护 9 棵索引树，插入性能极速下降。更尴尬的是，这些索引里大部分根本没有查询在用，纯粹是“觉得这个字段以后可能要用到”就建了。MySQL 里索引是“冗余”的数据结构，索引越多，写入和更新时的维护成本越高。正确的做法是：先用慢查询日志和SHOW INDEX找到真正被高频查询的路径，再针对性建索引。
关于索引的基数（Cardinality）这个概念，也值得展开说。索引列的去重值的数量就是基数，基数越高说明这个索引的区分度越好，查询时能过滤掉更多行。如果你是第一次查看索引效果，执行：
SHOW INDEX FROM orders;看到Cardinality接近表行数就说明这个索引区分度高，如果基数很低（比如性别字段只有 2 个值），普通索引就不太有价值。索引不是不能建低基数列，而是要理解它用在什么场景，比如联合索引里用它做前缀可以充分利用索引结构。
3.2 联合索引的字段顺序，决定了你的查询能不能走到索引
联合索引（复合索引）是 MySQL 索引设计里最核心的内容。核心原则是“最左前缀原则”：MySQL 使用联合索引时，会从最左边的字段开始匹配，一旦遇到范围查询或者跳过某列，后面的索引就失效了。
举个例子，我们有表结构：
CREATE TABLE orders ( order_id BIGINT PRIMARY KEY, user_id INT NOT NULL, status TINYINT NOT NULL, create_time DATETIME NOT NULL, KEY idx_user_status_time (user_id, status, create_time) ) ENGINE=InnoDB;这个idx_user_status_time联合索引，会高效支持以下查询：
SELECT * FROM orders WHERE user_id = 100; SELECT * FROM orders WHERE user_id = 100 AND status = 1; SELECT * FROM orders WHERE user_id = 100 AND status = 1 AND create_time > '2024-01-01';但是以下查询就可能无法完全走索引：
SELECT * FROM orders WHERE status = 1; -- 缺了最左边的 user_id，索引无效 SELECT * FROM orders WHERE user_id = 100 AND create_time > '2024-01-01'; -- 跳过了 status，create_time 那部分索引失效联合索引字段顺序的设计原则是把区分度高的、等值查询的字段放前面，范围查询字段放后面。如果你经常用user_id过滤、偶尔用status和create_time做组合过滤，这个顺序就没问题。反过来，如果status几乎全是等值条件、user_id偶尔才用，顺序就不合理，需要调整。
还有一个细节很多人不知道：MySQL 8.0 支持了SKIP SCAN特性，允许跳过联合索引最左列直接访问后面列，但这是有代价的，也不保证都走得上。不要把SKIP SCAN当成依赖，联合索引设计还是老老实实按最左前缀来。
3.3 慢查询的排查路上，EXPLAIN 是你的老朋友
写完 SQL 后，如果性能不对劲，第一反应应该是：
EXPLAIN SELECT * FROM orders WHERE user_id = 100 AND create_time > '2024-01-01';看type这一列，从好到差依次是：system、const、eq_ref、ref、range、index、ALL。ALL是全表扫描，遇到这个就要警惕了。Extra列里的Using filesort、Using temporary也是性能隐患，说明语句引发了排序或临时表，很可能是因为索引顺序和ORDER BY不一致。
说一个真实排查经历：业务上有个列表页，SELECT * FROM products WHERE category_id = 5 ORDER BY created_at DESC LIMIT 20，数据量 50 万，每次查询要 3 秒。EXPLAIN显示走了category_id的索引，但Extra里有Using filesort。解决办法是把索引改成(category_id, created_at)联合索引，这样索引内部已经按 category 和创建时间排好序了，排序操作彻底消失，查询时间降到 20ms 以内，连 SQL 都不用改。这就是索引设计的价值——有时候只是一行索引的事，性能能差两个数量级。
4. 数据的增删改操作，细节决定成败
INSERT、UPDATE、DELETE是每天都要写无数次的语句，看起来句子短、语法简单，但真要写得严谨、写得稳妥，里面装的都是坑。这里挑几个最值得展开的。
4.1 INSERT 的正确姿势：批量插入、默认值、冲突处理
关于写入性能，核心原则第一条就是：不要一条条插入。假设你要写 1 万行数据，一条条INSERT就要建立 1 万次事务连接，而一次INSERT多条记录（比如每批 500 条）只需要几次事务。批量插入对 InnoDB 特别友好，因为redo log写入会合并，整体性能和磁盘 IO 压力是量级的差别。
一个典型的批量插入：
INSERT INTO orders (order_id, user_id, amount, status) VALUES (1001, 20, 59.90, 0), (1002, 21, 129.00, 0), (1003, 22, 19.99, 1);如果你要插入的数据不是手工写的，而是来自另一个表，直接使用INSERT ... SELECT：
INSERT INTO orders_backup (order_id, user_id, amount, status) SELECT order_id, user_id, amount, status FROM orders WHERE create_time < '2023-01-01';但注意，INSERT ... SELECT在大表上执行时要控制好批次或者加LIMIT，否则会长时间锁住源表，也可能让 binlog 体积瞬间爆炸。
默认值和默认值相关的坑也需要单独说。MySQL 建表可以指定DEFAULT，比如status TINYINT NOT NULL DEFAULT 0。在很多代码里，INSERT语句如果不带status字段，就会自动填0。但如果你数据库的sql_mode很严格（比如STRICT_TRANS_TABLES），在NOT NULL且无默认值的字段上插入NULL，MySQL 会直接报错；而在非严格模式下，它可能会自动转换成隐式值（比如空字符串或 0），这就会导致业务数据不符合预期。建议统一开启严格模式，并且在建表时给每个字段都明确设置默认值，不要在默认值上留空白。
关于主键冲突，INSERT ... ON DUPLICATE KEY UPDATE是非常实用的语句，它能在主键或唯一键冲突时更新相应记录。这里有一个容易被忽略的点：这个语句不只会在遇到主键冲突时生效，任何唯一索引冲突都会触发更新行为。如果你的表有多个唯一键，一个插入值同时撞了两个，那更新行为可能会和你预期不太一样，建议日志里多观察。
4.2 UPDATE 的条件写错，是删库跑路的头号嫌疑人
UPDATE的风险不用我多说。一条UPDATE忘写WHERE，全表数据全变，MySQL 默认autocommit=1，执行后连后悔的机会都没有。我见过不止一次实习生在测试环境执行UPDATE users SET status = 1没加条件，把全表状态改了——如果这是生产环境，后果不堪设想。
所以，深刻价值的一句话：UPDATE 和 DELETE 前，先 SELECT 一遍同样条件的记录，确认影响范围。
-- 先查 SELECT COUNT(*) FROM users WHERE status = 0 AND register_time < '2023-01-01'; -- 再改 UPDATE users SET status = 1 WHERE status = 0 AND register_time < '2023-01-01';此外，一定要关注UPDATE和DELETE是否走了索引。MySQL 对每一条要修改的记录需要先定位到具体位置，定位效率取决于 WHERE 条件是否命中索引。如果WHERE字段没有索引，更新操作会逐行扫描表，Impact 范围极大，甚至可能锁住大量行，引发业务等待。
再说一个和锁相关的关键场景。UPDATE操作默认会加行锁，但如果你在对事务里先SELECT，再在后续UPDATE中更改条件，就可能出现锁等待甚至死锁。在高并发写入同一张表时，尽量保证操作的顺序一致，比如所有更新都按user_id从小到大执行，能显著降低死锁概率。这个问题在转账场景特别突出——A 给 B 转，同时 B 给 A 转，如果两条事务的加锁顺序不一致，死锁就出现了。
4.3 DELETE 并不省心：表空间、数据恢复和 TRUNCATE 的区别
DELETE FROM t WHERE ...删的是记录，但 InnoDB 并不会立刻把磁盘空间还给操作系统，它只是把记录标记为删除，空间留给了后续插入复用。如果表经常删除、插入，碎片会越来越多，表文件变大但实际行数不多。这时候执行OPTIMIZE TABLE t可以重建表并回收碎片，但同样，这个操作在大表上也要安排在业务低峰期。
另一个高频问题是“误删数据怎么恢复”。如果 MySQL 开启了 binlog，事务写操作都会记录在 binlog 里，你可以通过mysqlbinlog工具把 binlog 解析出来，找到误删的时间点并回放。但现实是很多中小团队根本没有开 binlog，一旦误删就只能从备份恢复，恢复粒度只能到备份时刻，那几小时甚至一天的数据就丢了。真的很容易断言：生产环境必须开 binlog，且必须定期全量备份+binlog 日志备份放到异地。
TRUNCATE TABLE t和DELETE FROM t的区别也是新人必踩的坑：
DELETE FROM t是一条条删，可以带 WHERE，日志记录完整，误删可以尝试用 binlog 恢复，但速度慢。TRUNCATE TABLE t是直接把整个表的数据页清空重建，速度极快，但不记录逐行日志，一旦执行无法通过 binlog 精确恢复，而且自增计数器会被重置。
如果你的目的是清空一张表后重新写入，用TRUNCATE；如果要删除部分数据或者允许回滚，用DELETE。永远不要在生产环境里随手敲TRUNCATE，它是一个“反悔药”都没有的操作。
5. 锁机制和事务，是表操作里最深的水
既然提到了死锁和行锁，这里就不可能不把 MySQL 的锁机制讲透。锁是 InnoDB 实现事务隔离性的关键手段，理解锁的分类和触发条件，你才能真正把控并发场景下的表操作。
5.1 InnoDB 锁的分类：按粒度、按模式、按算法
从粒度上分，锁分为表级锁和行级锁。MyISAM 只有表级锁，读锁共享、写锁互斥；InnoDB 支持行级锁，但也存在表级锁（比如 DDL 时的元数据锁 MDL）。
从模式上分，行锁主要有共享锁（S Lock，读锁）和排他锁（X Lock，写锁），两者的兼容性关系是：
| 锁模式 | 共享锁 S | 排他锁 X |
|---|---|---|
| 共享锁 S | 兼容 | 互斥 |
| 排他锁 X | 互斥 | 互斥 |
用 SQL 直接控制就是SELECT ... LOCK IN SHARE MODE加共享锁，SELECT ... FOR UPDATE加排他锁。业务上大部分写操作会隐式加排他锁，不需要手动加。
从算法上分，InnoDB 有三种重要的锁实现方式：
Record Lock（记录锁）：锁住索引上的一行记录。Gap Lock（间隙锁）：锁住索引记录之间的间隙，防止其他事务在范围内插入新记录，主要解决幻读问题。Next-Key Lock：记录锁和间隙锁的组合，锁住一个范围且包含记录本身，是 InnoDB 在 RR 隔离级别下的默认加锁策略。
很多人以为死锁只有在显式加锁时才会出现，其实不是。两个事务各自 UPDATE 一批重叠数据时，如果加锁顺序不一致，InnoDB 会在检测到死锁后回滚其中一个事务。报错信息形如：
Deadlock found when trying to get lock; try restarting transaction处理死锁的办法不是逃避，而是：保持事务尽量短、避免大事务、保持多行操作时加锁顺序一致、让涉及的数据量尽量小。
5.2 事务隔离级别：口口相传的“默认可重复读”到底保护了什么
MySQL 默认的隔离级别是REPEATABLE READ（可重复读）。在这个级别下，事务内多次SELECT的结果一致，同时通过Next-Key Lock避免幻读（不过只是在特定条件下）。如果你把隔离级别降到READ COMMITTED，每次SELECT看到的都是其他事务已提交的最新结果，并发读写能力会提高，但会引入不可重复读的问题。
我自己处理过很多因为隔离级别理解不清而出现的线上 Bug。举个例子：一个订单系统在秒杀场景下，先SELECT库存看是否足够，再UPDATE库存减一。两个并发事务同时读到了库存 5，然后各自执行UPDATE，如果不加FOR UPDATE或者不依赖数据库原子更新，最终库存可能变成 4 而不是 3。解决办法有二：要么用UPDATE stock SET count = count - 1 WHERE product_id = ? AND count > 0这种原子操作，要么先SELECT ... FOR UPDATE给库存行加锁。前者更简单高效，推荐优先用。
另外一个高频点是隐式提交。在 MySQL 中，DDL语句（建表、改表、删表）和TRUNCATE都会导致当前事务隐式提交。也就是说，你在一个事务里执行了UPDATE，还没 commit，突然又跑了一条ALTER TABLE，前面的事务直接被提交了，之前期望的“一起成功一起回滚”就失效了。写存储过程或者复杂事务时尤其要小心这种隐式提交陷阱。
5.3 锁等待超时，这张表怎么救
日常运维中，Lock wait timeout exceeded是高频报警之一。两个常见原因：一个事务持锁时间太长，另一个事务排队等锁等超时。
遇到这个报错，第一步是查当前有哪些事务在跑、锁等在哪张表：
SELECT * FROM information_schema.INNODB_TRX; SELECT * FROM information_schema.INNODB_LOCK_WAITS; SELECT * FROM information_schema.INNODB_LOCKS;通过这些视图能直观看到哪个事务正在阻塞、持锁多久了。如果是长事务持锁导致大量业务阻塞，可以考虑直接KILL掉持锁的会话进程。但更重要的还是找到根本原因——为什么事务会持锁那么久？是不是事务里有慢查询？是不是事务里混了外部接口调用？把这些被动等待转化成主动监控，才是治本的思路。
这里有一个非常实用的建议：事务代码里尽量只包含数据库操作，不要夹带远程 HTTP 调用、文件读写、消息发送等耗时操作。一个事务的执行时间越短，锁持有的时间越短，死锁和锁等待的概率就会极速下降。这是我多次踩坑后得出的最重要的一条，没有之一。
6. 实战经验：表操作的几个高频事故场景
从建表到索引、从 DML 到锁机制，前面把核心概念拆开了。这一节我直接列出几个真实发生过的场景，方便你对号入座。
6.1 场景一：alter 表时业务卡死
曾经遇到一个支付相关的核心表，每天新数据上百万，某天夜里 DBA 执行了一个ALTER TABLE加索引，结果加锁期间写操作全部阻塞，线上支付接口超时率飙升。当时就是直接用了原生的ALTER TABLE ADD INDEX，表太大用了 Copy 算法。如果你也遇到类似情况，建议走pt-online-schema-change工具，或者至少用ALGORITHM=INPLACE并在业务低峰期执行。执行前必须评估表数据量和索引大小，不要对核心生产表轻易执行原生 DDL。
6.2 场景二：排序查询越来越慢
某系统有个用户行为表，超过 2000 万行，分页查询加ORDER BY create_time DESC越来越慢。排查时发现查询条件走的是user_id索引，但排序字段没有索引，每条数据都要先取出来再 filesort。解决办法就是在联合索引里加上create_time字段。不要小看这个调整，排序消除是 MySQL 查询性能优化的一个核心手段，让索引自带的顺序帮你完成 ORDER BY，在很多场景下比增加任何查询缓存都管用。
6.3 场景三：表空间异常膨胀
透明化监控某天报磁盘使用率 90%，排查发现一张记录操作日志的表，每天写入量大，但定期删除却用了DELETE，没有配合回收表空间。日积月累，表数据页里布满了空洞，文件很大但实际行数不高。处理方式是先DELETE旧数据，在业务低峰期执行OPTIMIZE TABLE重建表释放空间，后续改成按天分区表，删除直接 drop 分区，彻底解决碎片问题。分区表在日志型数据场景下是终极武器，但要注意索引设计上分区键必须包含在 WHERE 条件里，否则查询要扫全部分区，性能比不分区的表还差。
7. 一些关于表设计与管理的心得
最后再讲几个偏“管理层面”的小经验。这些经验不像语法那样有标准答案，但它们是实际项目里验证过、能帮你省很多心的事。
第一，维护一份数据字典。很多人建表全靠 Navicat 图形界面，点几下就完成了，等哪天真要写复杂报表，根本不知道某张表里哪个字段是干什么的、谁是外键关系。用COMMENT给表、给字段都写上说明，最好再导出成文档定期更新。这个事情看着麻烦，但长期受益极大，尤其当你需要交接代码或者接手别人项目的时候。
第二，表和字段的命名要统一。项目里有user_name、又有username、还有userNick，这种混乱的命名会让你写 SQL 时经常怀疑自己记错了。拉一个大盘，把重复表、含义模糊的字段梳理一遍，能合并的合并，该废弃的废弃。SQL 是给人看的，也是给机器跑的，清晰一致比炫技重要。
第三，小表的操作也不能掉以轻心。很多人对大表战战兢兢，对小表随手就是ALTER TABLE、DROP TABLE。但小表也可能承担着高频访问，如果把业务正在查询的小表锁住几秒，一样会引发线上抖动。任何表结构变更都最好走同样的评估流程：评估影响行数、评估锁时间、评估并发依赖。
MySQL 的表操作是一个越深入越觉得自己无知的方向，从字符集、字段类型到索引、锁、事务，每一步都牵连着线上性能和稳定性。我这些年在实际项目里踩过的坑远不止文里写的这些，但最核心的教训就一条：别把表操作当小事，建表前的每一个决定、ALTER 时的每一次执行，都要想清楚代价。希望这篇文章能帮你把这些基础环节夯实，少走一些我走过的弯路。
