企业官网建设流程全解析

数据表是 MySQL 存储数据的核心载体，上一课我们搞定了数据库本身的创建和删除，但那只是搭好了“仓库”。真正的业务数据，全都要落在表里面。这一课我们就把数据表彻底玩明白：怎么把一张表建得既合理又够用，建完之后怎么把它的结构、状态看清楚，以及什么时候可以放心地把它删掉。

很多新手在学完建库之后，容易卡在一堆 SQL 语法上，其实数据表的操作就那么几个动作，难点不在命令本身，而在“为什么要这么建”。比如主键到底该不该用自增？varchar 长度是不是越长越好？删表和清空表有什么区别？这些细节直接影响你后面写业务代码和排查问题的心情。

这篇教程会从设计思路讲起，把创建、查看、删除三个动作拆开揉碎，每一步都带上实操命令和踩坑提醒。学完之后你应该能做到：拿到一张业务表的需求，能独立设计出字段合理的表结构；看到线上报错，能快速定位是表结构的问题还是数据的问题。

1. 动手建表前，先把这几件事想清楚

很多初学者的习惯是拿到需求就写 CREATE TABLE，字段名随手敲，类型靠感觉选。这个习惯很危险。表结构一旦上线，后面改起来成本极高，更别说数据量大之后 ALTER TABLE 会锁表。所以建表之前，先花十分钟把设计捋清楚。

1.1 表结构设计的三个常见误区

第一个误区是真假字段不分。比如用户表里要不要存“年龄”？严格来说年龄是可以通过出生日期算出来的，属于派生数据，存了反而要维护一致性，用户过生日你还得跑任务去更新它。正确的做法是存 birth_date，用的时候计算年龄。这个原则叫“数据只存一份，其余靠计算”。

第二个误区是过度设计。一上来就搞一大堆冗余字段、预留字段，比如“备用1、备用2”这种 column，看着像是为了将来扩展，实际上 90% 的备用字段一辈子都用不上，还白白增加表的宽度和麻烦。MySQL 单表字段数建议控制在 20 到 30 个以内，够用就好。

第三个误区是忽略命名规范。字段名、表名到底用驼峰还是下划线？在 MySQL 社区里，几乎约定俗成地使用小写加下划线，比如 user_name 而不是 userName 或 UserName。不做统一规范的表，后面写 SQL 同事之间互相看，都是折磨。

1.2 一张业务表的基础构成

在动手写 CREATE TABLE 之前，先在心里把一张表拆成四个部分：主键、普通业务字段、状态字段、时间字段。

主键每张表必须有，这是你和数据之间的“身份证”。没有主键的表，后面做数据更新、去重、定位问题都会非常痛苦。主键的选择上，我推荐用 BIGINT UNSIGNED AUTO_INCREMENT，单独一个无业务含义的自增 ID，别把身份证号、手机号这类业务值当主键，业务值会变，变了你会想哭。

普通业务字段就是真正记载业务数据的列，它设计的好不好，取决于你字段类型和宽度的选择。这个我们放到下一节细说。

状态字段和时间字段是很多表都会有的“基础设施”。状态字段比如订单的 status，用 TINYINT 存数字状态码，0、1、2，比直接存字符串“待支付”“已支付”省空间也更容易加索引。时间字段标准做法是两个：create_time 和 update_time，前者记录插入时间，后者记录最后更新时间。

1.3 一个前摇示例：用户表的字段设计

光说不练假把式。我带你设计一张最经典的用户表，字段包括：id、用户名、手机号、邮箱、密码摘要、性别、出生日期、状态、创建时间、更新时间。

id 用 BIGINT UNSIGNED AUTO_INCREMENT；用户名用 VARCHAR(50)，因为用户名一般不会超过 50 个字符，太长浪费；手机号用 CHAR(11)，手机号是固定长度，用 CHAR 比 VARCHAR 更省空间。密码摘要用 CHAR(32) 存 MD5 或者 CHAR(64) 存 SHA2，长度必须按算法固定长度来；性别用 TINYINT，0 未知 1 男 2 女；出生日期用 DATE；状态用 TINYINT，1 正常 0 禁用；创建和更新时间用 DATETIME。

这张表设计下来，每个字段都有明确的类型和长度依据，而不是拍脑袋决定。这个能力是数据表操作最值钱的部分，CREATE TABLE 语法只是最后那一下“落笔”。

2. 创建数据表：从 CREATE TABLE 到字段约束

设计想清楚了，现在动真格地写 SQL。很多人背不下 CREATE TABLE 的语法，其实你把它当成“列清单 + 表选项”两段式，就很好理解。

2.1 CREATE TABLE 完整语法拆解

最基本的建表语句长这个样子：

CREATE TABLE user ( id BIGINT UNSIGNED AUTO_INCREMENT COMMENT '主键ID', username VARCHAR(50) NOT NULL COMMENT '用户名', phone CHAR(11) NOT NULL COMMENT '手机号', status TINYINT NOT NULL DEFAULT 1 COMMENT '状态：1正常 0禁用', create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (id), UNIQUE KEY uk_phone (phone) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

你看，括号里面每一行就是一个字段。字段的排列顺序也有讲究，长度较短、访问频繁的字段尽量往前放，这样 InnoDB 在存储行数据时的效率会高一点。当然这个优化幅度有限，入门阶段你知道有这回事就行。

括号结束之后的部分，就是表级别的选项和约束。ENGINE 指定存储引擎，DEFAULT CHARSET 指定默认字符集，COMMENT 给整张表加说明。表注释非常重要，我见过无数线上表没有任何 COMMENT，后人根本猜不到这张表是干嘛的，字段名也猜不到含义，只能去翻代码。所以，字段注释和表注释一定要写，这是基本职业素养。

2.2 字段类型选不对，后面全是坑

字段类型是整个建表过程中最容易“差不多得了”的地方，但偏偏它最影响性能和数据正确性。我给你划几个重点。

整数类型有 TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT，从 1 字节到 8 字节。选型的唯一依据是取值范围。比如状态码用 TINYINT，范围是 -128 到 127（无符号是 0 到 255），足够。用户数量可能过千万，甚至上亿，那就直接用 BIGINT，别用 INT，因为 INT 无符号上限是 42 亿，看着够，但一旦业务增长超预期，满表之后你会面临一个非常痛苦的改造。

小数类型记住一句话：钱永远用 DECIMAL，别用 FLOAT 和 DOUBLE。FLOAT 和 DOUBLE 是浮点数，计算会有精度误差，0.1 加 0.2 可能得到 0.30000000000000004。DECIMAL 是定点数，按字符串存储和计算，精度可控，定义方式 DECIMAL(10,2) 表示共 10 位数字，小数点后 2 位。价格、余额、利率统统用它。

字符串类型里，定长用 CHAR，变长用 VARCHAR。CHAR(11) 存手机号，无论内容多长都占 11 字符空间，读取快；VARCHAR(50) 最长 50 个字符，实际存多少占多少，额外用 1 到 2 个字节记录长度。VARCHAR 的长度也不是越大越好，MySQL 对行有 65535 字节的限制，VARCHAR 字段过长会让行变得臃肿，而且建立索引时，太长的字段会导致索引体积暴涨，甚至触发索引长度限制。

时间类型用 DATETIME，不要用 TIMESTAMP。DATETIME 范围是 1000 年到 9999 年，TIMESTAMP 只能到 2038 年。虽然距离 2038 年还有段时间，但线上系统谁不想活到那一天？DATETIME 不依赖时区，TIMESTAMP 会自动转换时区，容易造成显示混乱。

2.3 主键、默认值、自增和唯一约束怎么搭配

主键是刚需，这个前面已经强调过了。建表的时候直接把 PRIMARY KEY (id) 写在表级约束里，或者写在字段后面id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY都可以。两种写法自己选，我习惯分开写，结构清楚。自增主键的两个要点：第一，类型必须是整数类型；第二，搭配 UNSIGNED，尽量用 BIGINT，32 位的 INT 是小马拉大车，没必要省。

NOT NULL 和 DEFAULT 是配套的。凡是不能为空的字段，都要显式加 NOT NULL，同时尽量给一个 DEFAULT。比如状态字段给 DEFAULT 1，创建时间给 DEFAULT CURRENT_TIMESTAMP。这样业务代码在插入数据时可以省掉这些字段，不用每次都手动填，减少出错面。我这里强烈建议：除了主键和业务上确实没有默认值的字段，其他字段都尽量给 DEFAULT，能有效规避很多“空值地狱”问题。

UNIQUE KEY 用来做唯一约束。手机号、邮箱这类业务上必须唯一的字段，除了业务代码判断之外，数据库层面一定要加唯一索引兜底，这是保护数据完整性的最后一道防线。注意 NULL 在唯一索引里是特殊的，多个 NULL 可以共存，所以如果字段要做唯一索引，提前想清楚业务上允不允许 NULL。

AUTO_INCREMENT 还有一个细节：它只能作用于整数类型字段，而且一张表只能有一个自增列，并且它必须被定义为键（通常是主键）。自增列不重不漏，是保证行数据唯一身份的机制，不要手动往自增列里插值，会导致下次自增编号跳跃。

2.4 ENGINE 和 CHARSET：提前定好，别后补

CREATE TABLE 里最容易被默认值坑的就是存储引擎和字符集。MySQL 5.7 之后默认引擎就是 InnoDB，默认字符集是 utf8mb4，但很多老系统、老配置可能不是这样。

存储引擎的选择上，你几乎不需要考虑 MyISAM。MyISAM 不支持事务、不支持外键、崩溃恢复能力差，唯一优势是某些只读场景下查询略快，但代价是数据安全性太差。做业务的表一律 InnoDB，支持行级锁、支持事务、支持崩溃恢复，这是底线。

字符集一定要显式指定 utf8mb4。注意要区分 utf8 和 utf8mb4 的坑，MySQL 的 utf8 实际最多存 3 字节，而 emoji 表情和一些特殊字符需要 4 字节。如果建表时用了 utf8，以后插入 emoji 直接报错。utf8mb4 是完整的 UTF-8 编码，无论中文、英文、emoji 都能存。排序规则一般用 utf8mb4_unicode_ci 或者 utf8mb4_general_ci，前缀 ci 表示大小写不敏感。日常业务选择这两种之一即可，它们都能满足大多数场景。

这里有个容易忽略的点：如果你在库级别设置了 utf8mb4，建表时不指定 CHARSET，会默认继承库的字符集，这个继承行为可靠，但最好还是每张表显式写清楚，防止将来有人直接把表迁移到其他库、或者其他同事看表定义时不够一目了然。

2.5 完整实操：复制一个“订单明细表”

看完了语法和类型，我们完整走一遍建表过程。假设要建一张订单明细表，存订单里的每个商品条目，字段有：明细 ID、订单 ID、商品 ID、商品名称、购买数量、成交单价、小计金额、创建时间。

CREATE TABLE order_item ( id BIGINT UNSIGNED AUTO_INCREMENT COMMENT '明细ID', order_id BIGINT UNSIGNED NOT NULL COMMENT '订单ID', product_id BIGINT UNSIGNED NOT NULL COMMENT '商品ID', product_name VARCHAR(255) NOT NULL COMMENT '商品名称快照', quantity INT UNSIGNED NOT NULL DEFAULT 1 COMMENT '购买数量', price DECIMAL(10,2) NOT NULL COMMENT '成交单价', subtotal DECIMAL(10,2) NOT NULL COMMENT '小计金额', create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (id), KEY idx_order_id (order_id), KEY idx_product_id (product_id), KEY idx_create_time (create_time) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单明细表';

注意到几个细节：product_name 是“快照”，意思是下单那一刻的商品名字，即使后面商品改名了，订单里依然保留当时的名字，这是业务历史留痕的典型做法。两个 DECIMAL 字段都定义了 10,2，金额计算不会丢精度。交集查询会走到 order_id 和 product_id 上的普通索引，这就是 KEY 的作用。索引不是越多越好，但常用的 WHERE 过滤字段适度建立索引，能显著提升查询速度，这个知识点后续课程还会展开。

建完表之后，用 SHOW TABLES 看下当前库里都有哪些表，用 DESC order_item 看一眼结构，确认无误再接入业务。这个过程就是数据表操作的第二个阶段：查看。

3. 查看数据表：信息在手，改表不愁

建表只是开始，日常维护中，你需要不停确认表的状态：这张表有哪些字段？字段类型是什么？索引结构如何？字符集对不对？甚至表占用了多少空间。MySQL 提供了几套查看体系，我们用全一点。

3.1 SHOW TABLES：查看库下所有表

最基本的命令是SHOW TABLES;，执行之后列出当前数据库所有表。此时不加 WHERE 条件也可以，想显示更丰富的信息，比如表类型、存储引擎、数据长度等，可以用SHOW TABLE STATUS LIKE 'order_item'\G;，它会返回一张大宽表。

如果不确定表名，可以用 LIKE 做模糊匹配：SHOW TABLES LIKE 'order%';，匹配所有以 order 开头的表。这在库里面表很多，名字类似的情况下非常有用。还有一种更灵活的查询，直接查 information_schema 库：

SELECT table_name, engine, table_rows, create_time FROM information_schema.tables WHERE table_schema = '你的库名';

information_schema 是一个系统库，里面记录了 MySQL 的元数据，也就是关于数据的数据。这个写法的好处是可以按任意条件过滤，甚至做表大小的排序，这在排查“哪个表占空间最大”的时候特别有用。

3.2 SHOW CREATE TABLE：拿到一张表的完整身世

SHOW CREATE TABLE order_item;会返回建表语句的完整定义。这是我最喜欢的查看命令，没有之一。它会把当前表的引擎、字符集、每个字段的约束、所有索引，原汁原味地展示出来，和你当初写的建表语句略有差异，因为 MySQL 会在内部对语法做一些规范化，比如把 INT(11) 显示成 int 或把 COMMENT 展示出来。

当你需要把一张表的建表语句复制到别的环境、或者需要和同事讨论表结构时，先用这个命令拿到准确版本，再复制粘贴。比你自己从记忆里重新拼一个 CREATE TABLE 靠谱一百倍。如果你要迁移表结构不迁移数据，这也是源头，直接把结果导出即可。

注意：执行 SHOW CREATE TABLE 返回结果里可能有\G的展示格式，在命令行客户端中，结尾加\G可以让结果纵向输出，避免列数太多时折行，字段和值各占一行，看起来特别清晰。Windows 的 cmd 下如果显示乱码，检查一下客户端的字符集设置。

3.3 DESC 命令：快速浏览表结构

DESC 全称是 DESCRIBE，语法DESC order_item;或者DESCRIBE order_item;。它会列出字段名、类型、是否允许 NULL、键信息、默认值、额外属性，基本上是你最常用来确认“某张表里有没有某个字段、类型是什么”的命令。

DESC 输出的信息虽然好读，但它不会展示表级选项（引擎、字符集、注释），也不会把索引信息独立展示出来。要看完整索引，配合SHOW INDEX FROM order_item;来查。SHOW INDEX 的输出列很多，关键看三个：列名（Column_name）、索引名（Key_name）、索引顺序（Seq_in_index）。联合索引里字段顺序对不对，全靠这个命令校验。

如果你只想确认某个字段是否存在，可以DESC order_item 字段名;，但 MySQL 官方并不推荐这种传入字段名的用法，实际项目中我几乎都是先 DESC 整张表再用命令工具搜索字段名字，反而更快。用可视化工具如某数据库管理软件的话，直接点开表就能看，命令行的能力也得会，因为线上服务器排查问题多数时候只能连命令行。

3.4 查看表数据与统计信息

查看表不能只停留在表结构层面，数据本身也要能看。最简单的是SELECT * FROM order_item LIMIT 10;，带回前 10 行。新手务必养成LIMIT的习惯，线上表可能几十万行，直接SELECT *会把数据库打挂或者把客户端客户端搞到卡死。

统计信息方面，SELECT COUNT(*) FROM order_item;是精确行数，这是全表扫描行为，对大表开销很大。而SHOW TABLE STATUS里的 rows 字段是估算值，来自索引统计数据，不精确，但速度快。如果你只需要“大概多少行”来做容量判断，后者完全够用，别动不动就跑 COUNT(*)，尤其在生产环境。

数据文件占用大小也可以查，比如数据目录里每个表文件的大小，但命令行的优雅方式是查 information_schema：

SELECT table_name, ROUND((data_length + index_length) / 1024 / 1024, 2) AS '大小(MB)' FROM information_schema.tables WHERE table_schema = '你的库名' ORDER BY (data_length + index_length) DESC;

这张 SQL 能很快定位到哪些表是“大胖子”，撑起了库里的空间，是排查磁盘空间和慢查询的前置动作。

4. 删除数据表：DROP TABLE、TRUNCATE、DELETE 到底怎么选

删除操作是数据表操作里最需要敬畏的一环。很多新人分不清“删表”和“清空表”“删行”的差异，一句话说清：DROP 是连表带结构一起消失，TRUNCATE 是清空所有行但保留表结构，DELETE 是删行可以带条件可以回滚。这三个动作对应完全不同的应用场景。

4.1 DROP TABLE：连根拔起

DROP TABLE order_item;会删除整张表，包括表结构和所有数据，以及与之相关的索引、触发器、约束。表空间释放，表名字从 information_schema 里消失。这是一条不可恢复重来的操作，除非你有备份。

加IF EXISTS可以避免报错：DROP TABLE IF EXISTS order_item;。当表不存在时，不报错只给一个 warning。这个写法在写自动化脚本、初始化脚本时非常有用，重复执行也不担心。批量删除多张表也支持，DROP TABLE IF EXISTS table1, table2, table3;。

删除表时如果有外键关联，MySQL 会检查表之间是否有引用关系。默认情况下，你会先删了被引用方再删引用方，或者用SET FOREIGN_KEY_CHECKS = 0;临时关闭外键检查，删完再恢复成 1。生产环境我不建议动这个开关，表设计时就应该规划好外键关系，该按顺序删就按顺序删。

不管什么理由执行 DROP TABLE，动手之前先问自己三个问题：这张表有备份吗？下游有没有依赖它的脚本或者报表？是不是业务真的不需要这张表了、而不是只要清空数据？血泪教训，我见过同事误把生产表 drop 掉，最后靠昨天凌晨的备份恢复，中间十几个小时的数据全部对不上，连续救了两天。别让你的手快成为事故现场。

4.2 TRUNCATE 和 DELETE 的区别与选择

TRUNCATE TABLE 和 DELETE FROM 都删数据，但底层逻辑完全不同。

TRUNCATE 是 DDL 操作，它做的事是直接把整张表重建一遍，保留表结构但重置自增 ID，同时释放存储空间。它不能带 WHERE 条件，一执行就是全表清空。因为它是通过“重建表”实现的，执行速度极快，哪怕是几百万行的表也能瞬间完成。但代价是不可回滚、没有事务保护。

DELETE FROM 是 DML 操作，逐行删除，可以加 WHERE 条件，删除过程受事务保护，如果发现删错了可以 ROLLBACK 回滚。代价是慢，尤其表很大、删的行很多时，会产生大量 binlog，还有可能长事务锁表。

所以选型规则很明确：只删部分数据、需要回滚保护，用 DELETE；确定全部数据都要不要了、还要自增 ID 从头开始、而且能接受不可回滚，用 TRUNCATE。注意 TRUNCATE 在 MySQL 里不能对带有外键引用的父表操作，会被报错，需要先删子表或跳过外键检查，这一点很重要。

写 DELETE 之前一定先 SELECT 同条件确认：先SELECT COUNT(*) FROM order_item WHERE create_time < '2024-01-01';，再用同样的 WHERE 去 DELETE，避免手滑把不该删的东西删了。

4.3 误删了怎么办：自救思路与备份意识

误删表之后别慌，第一时间评估损失范围。有没有最近的物理备份？有没有 binlog 可以追溯？如果你的数据库开了 binlog，并且日志格式是 ROW，理论上可以基于时间点或基于位点把数据恢复到误删之前的最后一刻；如果没有备份也没有 binlog，那只能自求多福。

恢复的正确姿势永远是“备份 + binlog 回放”。我的建议是，从第一天做开发开始就养成“重要表必须天天备份”的习惯，哪怕是手动 mysqldump，也比裸奔强。删除操作的每一步，能用事务包裹的尽量先 BEGIN，确认无误再 COMMIT，给反悔留个机会。DROP TABLE 无法用事务包裹，那就退一步：执行 DROP 前先把建表语句 SHOW CREATE TABLE 导出来，把数据用 SELECT INTO OUTFILE 或 mysqldump 备份一份，再动手。

5. 常见问题与排查技巧实录

数据表操作看着简单，实际跑起来总会遇到一些阴暗角落的问题。我把这几年排查过程中踩过的典型坑整理成速查表，都是我实际经历过的报错和解决路径，新手建议直接收藏。

5.1 建表报错的经典场景

第一个经典报错是ERROR 1064 (42000): You have an error in your SQL syntax。这种基本是语法层面的问题，比如字段之间漏了逗号、字符串用了双引号而不是单引号、括号不匹配。排查方法很简单，把 SQL 复制出来逐行检查，不放心就拆成最简单的 CREATE TABLE 再加字段，逐步排错。命令行客户端对语法的提示挺弱，我遇到这类问题最多的情况是在字符串里用了中文引号或全角逗号，肉眼很难发现。

第二个经典报错是ERROR 1046 (3D000): No database selected。如果你执行 CREATE TABLE 之前没有USE 数据库名;，就会遇到这个。解决办法是先用 USE 切库，或者在 CREATE TABLE 语句里写成CREATE TABLE 库名.表名 (...)。全限定名的方式在脚本里更省心，不用依赖当前连接选的库。

第三个经典报错是ERROR 1005 (HY000): Can't create table，常见于外键关联的场景，比如关联的表的字段类型不一致、被关联表不存在、或者被关联字段没有索引。这个报错比较笼统，看 MySQL 详细错误日志的 last_errno 会更明确。日常业务表，我反正不太建议用物理外键，业务完整性通过代码控制就好，外键在分布式和弹性扩展场景里反而是累赘。

5.2 表结构改错了怎么办：ALTER TABLE 的基础操作

建表之后发现漏了个字段，这太正常了。不需要把表删了重建，用 ALTER TABLE 可以动态修改表结构。

ALTER TABLE order_item ADD COLUMN discount DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT '折扣金额' AFTER price;

这条命令会在 price 字段后面新增一个 discount 字段。AFTER 用来控制新字段的物理位置，不加的话默认追加到表末尾。注意，如果表已经有大量数据，ADD COLUMN 在 InnoDB 里是 Online DDL，5.7 以上的版本一般不用锁表，但也不是完全没有成本，尽量选业务低峰期执行。

修改字段类型用ALTER TABLE order_item MODIFY COLUMN price DECIMAL(12,2) NOT NULL COMMENT '成交单价';。这里强烈警告：缩短字段宽度要极其谨慎，比如把 VARCHAR(255) 改小成 VARCHAR(50)，如果已有数据超出 50 字符，会直接报错，或者更糟的是在数据截断警告下把超出部分静默截掉，造成数据丢失。修改前先查一下最大长度是多少再决定，稳妥做法是先用引号包住 SQL 备份原字段定义，万一改错了能改回去。

重命名字段用ALTER TABLE order_item CHANGE COLUMN old_name new_name 类型;，注意 CHANGE 必须重新写一遍完整字段定义，少写了约束，约束就会丢。删除字段用ALTER TABLE order_item DROP COLUMN discount;，删除字段后，该列的数据和索引都会一并消失，如果字段上建有索引，索引也会随之更新，这个操作也是不可逆的，先确认真的没有业务在用它。

5.3 给入门者的几条实操铁律

第一，所有破坏性操作先备份。建库建表不用备份，DROP、TRUNCATE、大批量 DELETE 一定要有备份兜底。

第二，所有 SELECT 都要先想清楚要不要加 LIMIT。线上排查问题，数据几十万行是常态，一条全表扫描的 SELECT 就能让数据库 CPU 报警。

第三，建表时写 COMMENT 不亏。字段注释和表注释相当于给未来写文档，花了三秒钟，剩下的好处日后十倍百倍地还给你。

第四，不要在业务高峰期执行 DDL。ALTER TABLE、TRUNCATE、DROP 这类操作要挑夜深人静的时候。像 DROP TABLE 很快，但 ALTER TABLE 里的复制表操作可能很慢，尤其是大表，影响面会被放大。

第五，命令执行之前先看一眼自己现在在哪个库，SELECT DATABASE();，这个习惯能避免你把测试环境的表删在生产库上。尤其刚建了多个项目库的人，切库看错是最容易犯的错。我自己的经历是，在测试库写好了 DROP 语句，复制到生产环境一执行，傻眼，生产库的表直接被删了，那感觉至今难忘。

6. 实操总结与个人体会

数据表的创建、查看、删除，语法上真没多少东西，一节课就能讲完。但真正拉开人和人差距的，是对表结构的理解和敬畏。

我见过太多人建表时图省事，乱选类型，不写注释，不做索引设计，等到数据量上来才开始加班救火。也见过有人小心翼翼，每张表都认真设计字段、挑选索引、写好 COMMENT，后来业务迭代得非常顺利，加需求改表几乎无痛。差别不在智力，在习惯。

我自己现在建任何一张表，都会先写一个设计草稿，把字段名列出来，标清楚类型和约束，再模拟几条业务数据走一遍场景，确认这些字段真的够用，最后才落 CREATE TABLE。有了新需求也不慌，ALTER TABLE 加字段即可，只要前期设计不是太离谱，后期的演进都是平滑的。

这一课的核心命令并不多：CREATE TABLE 建表、SHOW TABLES 和 SHOW CREATE TABLE 和 DESC 看表、DROP TABLE 删表，再加上 ALTER TABLE 改表。建议你把它们挨个在命令行里敲一遍，建几张不同结构的表，看看 SHOW CREATE TABLE 输出和你的输入有什么差异，再用 DESC 和 SHOW INDEX 把表结构读透。多练几遍，你的肌肉记忆就形成了。

最后一件事，练手时别用生产库，随便建一个练习库，造几张无关紧要的表，随便删、随便改，不会有人找你麻烦。数据表操作就是熟练工的活儿，多毁几张表，你就能真正掌控表了。