MySQL数据库与数据表操作全解：从建库到表结构维护的实战指南

直接点说，这篇是写给两种人看的：刚把 MySQL 装好、正对着黑乎乎的命令行发怵的新手，以及用过几年数据库但全是靠图形界面工具点来点去、从没正经敲过几行 SQL 的老伙计。我自己最早就是后者，总觉得会点鼠标就等于会数据库了，直到某次在服务器上排查问题，才发现连SHOW DATABASES;都敲不利索。从那时候起我就明白，数据库和表的基本操作，才是所有进阶功底的试金石，也是走捷径的唯一捷径。

这篇文章，我会用最贴近实操的方式，把 MySQL 里数据库和表的增删改查、数据类型选择、约束设计这些基础操作一次性讲透。每个命令不只是给你语法，还会告诉你为什么要这么写、执行后发生了什么、以及哪些坑我踩过你就别再踩了。看完你至少能独立完成一套完整的本地库表环境搭建，并且对后面要学的索引、事务、范式设计打下一个扎实的底子。

1. 数据库的基本操作与账号权限

1.1 从登录开始：命令行连接与常用参数

很多初学者第一步就卡在“怎么进 MySQL”。其实没那么多玄学，就是一条命令的事：

mysql -u root -p

回车之后会让你输入密码，验证通过就进入mysql>交互式命令行。这里必须说清楚几个容易被忽略的细节。

第一，-u和用户名之间可以有空格也可以没有，mysql -uroot -p和mysql -u root -p效果完全一样，但-p后面绝不能直接跟密码写在命令里，比如mysql -u root -p123456虽然能登录，但会造成密码被记录在 shell 历史记录里，存在严重安全隐患，任何有经验的人都不会这么干。

第二，如果你连接的是远程数据库，需要追加-h指定主机地址，-P指定端口，注意是大写的 P：

mysql -u root -p -h 192.168.1.100 -P 3306

默认端口就是 3306，本地连接可以不写。这个命令在排查开发环境连不上测试服务器数据库的时候几乎是必备。

第三，登录之后看到的mysql>提示符，指的是 MySQL 命令行客户端，它只接受分号结尾的 SQL 语句。很多人第一次敲show databases;时忘了分号，程序一直不执行，就以为是卡住了，其实不是，是服务器还在等你把语句写完。这一点反复碰到，建议一开始就养成每条语句以分号结尾的习惯。

我会建议新手别太依赖图形化工具。不是说 Navicat 这类客户端不好，而是命令行能逼你理解 MySQL 真正做了什么。你自己敲一次CREATE DATABASE，再在图形界面里点一次“新建数据库”，感受是完全不同的——前者让你意识到每个字符都是指令，后者只是替你生成了指令。做运维排查的时候，服务器上往往只有命令行可用，那时候你就知道基本功的价值了。

1.2 创建数据库与字符集选择

创建数据库，语法非常简单：

CREATE DATABASE 数据库名;

但实际操作中几乎没有人会这么裸写，因为数据库的“默认基因”——字符集和排序规则，是在创建这一刻定下来的。如果这一层没想清楚，后面表里的中文出现乱码，想在后期再改，那可比一开始建库时选对麻烦十倍。

我们最常用的完整写法是：

CREATE DATABASE IF NOT EXISTS shop DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

解析一下每个部分的含义。

IF NOT EXISTS是防呆设计。意思是如果这个库已经存在，就不做任何操作，也不报错。这在重复执行脚本时非常有用，尤其是部署自动化任务时，你不会想因为“库已存在”而让整个流程中断。

DEFAULT CHARACTER SET utf8mb4是指定默认字符集。为什么是utf8mb4而不是utf8？这是新手最常踩的坑之一。MySQL 里的utf8本质上最多只支持 3 字节的字符，像常见 Emoji 表情、生僻汉字，都是用 4 字节编码的，utf8字符集会直接报错或者变成乱码。utf8mb4是真正的、完整的 UTF-8 编码，兼容性最好。从 MySQL 5.5.3 版本之后，utf8mb4就已经是行业事实标准了。

COLLATE utf8mb4_general_ci是排序规则。ci表示 case insensitive，也就是大小写不敏感。这直接影响查询时的字符串比较行为，比如搜索abc时会不会把ABC也算进去。一般业务系统选utf8mb4_general_ci就够了，性能也好。如果你的数据涉及多种语言、需要非常精确的 Unicode 排序规则，可以考虑utf8mb4_unicode_ci，但绝大多数场景用不到。

我个人的习惯是：所有新建业务库，一律用utf8mb4起步，绝不给自己留后期改字符集的麻烦。数据库名字用英文小写加下划线，比如shop_order而不是ShopOrder，主要是避免 Linux 和 Windows 环境下大小写敏感差异带来的隐患。

验证是否创建成功，用两条命令：

SHOW DATABASES; SHOW CREATE DATABASE shop;

第二条能看到完整的建库语句，包括你刚才设置的字符集和排序规则。这招在排查库级配置问题时很实用。

1.3 删除、选择与当前库状态

删除数据库是整个 MySQL 里最“杀伐果断”的操作，语法是：

DROP DATABASE shop;

执行之后，这个库连同里面的所有表、数据、存储过程等一切内容都会永久消失。没有回收站，没有二次确认，你连“撤销”的机会都没有。DBA 老手操作这条命令时眼神都会变得格外警惕，因为太多线上事故都源于一句DROP DATABASE。

建议养成这些习惯：生产环境操作前先SHOW DATABASES;核对库名；脚本里不要直接裸写DROP DATABASE，至少加个环境判断变量；紧要关头先备份再动手。本地练习随便删没关系，生产环境务必敬畏。

选择数据库用USE语句：

USE shop;

执行后当前会话就会切换到这个库上。很多操作（比如后续的建表）都依赖于当前选中的数据库。这里有个小细节：MySQL 命令行客户端登录时也可以直接指定要用的库：

mysql -u root -p shop

登录后直接就处于 shop 库的上下文中，省得再敲一次USE。这在写自动化脚本时很好用。

还有一个常用命令是查看当前处于哪个库：

SELECT DATABASE();

如果返回NULL，说明你还没有USE任何一个库。写 SQL 时报错 “No database selected”，原因就在这。

数据库层面的基本操作就这些，掌握了登录、建库、删库、选库，你就完成了最基础的一环。接下来把焦点转到表，这才是真正天天打交道的对象。

2. 数据类型选型与原理理解

2.1 数值类型的正确选择

建表时第一关不是语法，而是字段类型怎么选。选错了要么浪费存储空间，要么数据存不下直接报错。数值类型我一般分三类说：整数、小数、布尔。

整数类型在 MySQL 里主要有TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT，区别就是占用的字节数不同、能表示的整数范围不同。

新手最常见的错误是，一个字段只会存 0 或 1，结果定义成了INT，白白浪费 3 个字节还看不出来。数据量小的时候无所谓，但一张千万行的表，每个字段多 3 个字节就是 30MB 的额外空间，索引性能也会受到牵连。

如果你确认某个字段只会存非负数，可以加上UNSIGNED属性，比如年龄字段用TINYINT UNSIGNED，取值范围就变成 0 到 255，更贴合语义。但主键 ID 我个人建议用BIGINT UNSIGNED，原因很简单：你不知道业务能活多久，主键一旦耗尽，扩表类型的代价非常大。

小数类型要特别强调：千万不要用FLOAT或DOUBLE存金额。这两个是浮点数，在计算机里用二进制近似表示，你会发现0.1 + 0.2的结果是0.30000000000000004，这在需要精确计算的财务场景里是致命的。正确做法是用DECIMAL，定点数类型，存储时就是精确的十进制数字。比如：

price DECIMAL(10,2)

表示这个字段最多 10 位数字，其中 2 位是小数部分，也就是最多能存 99999999.99，对于大多数电商场景的单价完全够用。涉及金额、余额、折扣等，一律DECIMAL，这是行业的铁律。

2.2 字符串类型与日期时间类型

字符串类型最常用的是CHAR和VARCHAR。两者的区别可以这么理解：CHAR是“定长”，VARCHAR是“变长”。

CHAR(10)不管存不存满，都占用 10 个字符的空间，不足的部分用空格补足，读取时会去掉尾部空格。VARCHAR(10)则是在存储时额外用一个或两个字节记录实际长度，只存实际内容。所以：

• 长度固定的数据，比如手机号、身份证号、MD5 哈希值，用CHAR更合适，没有额外长度开销，查询更快。
• 长度不定的数据，比如用户名、标题、简介，用VARCHAR，能省空间。

还有一个细节：VARCHAR在 4.0 以下版本里单位是字节，在 5.0 以上是字符。也就是说VARCHAR(100)在主流 MySQL 版本里可以存 100 个汉字，不是 100 个字节。这个差异在设置字段长度时很容易让人困惑，但记住“字符”这个概念即可，要确保长度设置能容纳你业务里最长的一条中文文本。

日期时间类型，常用的是DATETIME和TIMESTAMP。

DATETIME存的是一段绝对的日期时间，范围从 1000 年到 9999 年，不受时区影响。适合存用户生日、创建时间这类业务时间。

TIMESTAMP存的是从 1970 年 1 月 1 日到某个时刻的秒数，范围只能到 2038 年，而且会根据数据库服务器的时区自动转换。看到 2038 年是不是有点慌？其实对于基于 MySQL 5.5 之后的现代系统，存常规的时间戳没问题，但还是建议除非有特殊需求，大多数业务字段直接用DATETIME更省心。

创建时间、更新时间这样的字段，我常用这样的写法：

created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP

这样插入数据时不用手动填时间，更新时也会自动刷新updated_at，省去应用层不少代码。这个写法在做审计类需求时特别实用，强烈建议列入默认配置清单。

2.3 实际选型建议

讲完类型，我总结一张我自己用下来的选型对照表，你可以直接照着写表结构：

这里面有个常见疑问：长文本为什么不用TEXT？TEXT类型处理起来限制更多，比如不能有默认值、索引方式特殊，而且它和VARCHAR的存储机制有差异。业务上大多数“备注”字段实际都在 500 字以内，用VARCHAR(500)足够。真有大段富文本内容，直接上TEXT可以，但别滥用。

3. 数据表的创建与约束设计

3.1 一条完整的建表语句拆解

数据库建好之后，就是建表。我见过太多新手一上来就CREATE TABLE users (name varchar(50));，这种表在生产环境里过不了三关：没主键、没时间字段、没任何约束。真正的完整建表语句长这样：

CREATE TABLE IF NOT EXISTS `user` ( `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '用户ID', `username` VARCHAR(50) NOT NULL COMMENT '用户名', `phone` CHAR(11) DEFAULT NULL COMMENT '手机号', `email` VARCHAR(100) DEFAULT 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_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci COMMENT='用户表';

逐项说明一下。

反引号，就是这个符号，用来包裹表名和字段名，可以避免和 MySQL 关键字冲突。虽然user` 这类词在某些版本里是关键字，但你养成了给表名和字段名都加反引号的习惯，就永远不会遇到“语法明明没问题但就是报错”的怪事。

NOT NULL和DEFAULT NULL是控制字段是否允许为空。NOT NULL表示这条数据必须有值，DEFAULT NULL表示如果没有显式传值，就填 NULL。逻辑很简单，但设计时要思考业务上字段是否真的必须存在。

COMMENT注释是最容易忽略但最值得养成的习惯。三个月后的你会感谢今天写注释的自己。数据库是团队协作的底层资产，字段注释就是给后来者的指引。没注释的表结构，光是猜字段含义就够让人崩溃了。

AUTO_INCREMENT是自增属性，配合主键使用。每插入一条记录，这个字段会自动加一，省去应用层生成 ID 的麻烦。注意自增列必须定义为键（通常是主键），而且必须非空。

主键PRIMARY KEY (id)是每行数据的唯一标识，物理存储上主键还决定了数据在 InnoDB 里的排列方式，这就不多展开了，记住一点：几乎每张表都必须有主键，没有主键的表在复制、备份、更新删除时都会埋下雷。

UNIQUE KEY唯一约束，保证字段值在表里不重复，比如用户名不能重复。加了这个约束后，重复插入相同用户名就会直接报错，比应用层判断可靠得多。

ENGINE=InnoDB是存储引擎。除非你有非常明确的理由（比如临时缓存表用 MEMORY），否则一律 InnoDB。它支持事务、行级锁、崩溃恢复，是 MySQL 默认也是最佳的 OLTP 引擎。

3.2 五种约束的作用与使用场景

约束，本质上就是数据库替你把关的“规则”。我总结常用的五种：

第一，主键约束（Primary Key）。每张表最多只能有一个主键，它既保证唯一性，又自动创建索引，是查询的最快入口。在 InnoDB 里，主键更是“聚簇索引”的基础，直接影响数据的物理存放顺序。选择主键时，建议是“与业务无关的值”——自增数字、雪花 ID 都可以，但不要用身份证号、手机号这类业务含义太重的字段做主键，因为业务规则一变，主键很难改。

第二，非空约束（Not Null）。字段定义里的NOT NULL就是它。适合那些业务上一旦缺失就导致数据不可用或逻辑出错的字段，比如订单金额、用户ID。

第三，唯一约束（Unique Key）。保证值不重复，常用于手机号、邮箱、订单号等带唯一性的业务字段。注意唯一约束允许 NULL 值，而且 MySQL 里多个 NULL 不会被认为是重复值，这个机制和高深的索引原理相关，但你先知道这个现象即可。

第四，默认约束（Default）。字段定义里的DEFAULT就是它。当插入数据没传这个字段时，数据库会用默认值代替。好处是应用层少传参，数据完整性也有保障。比如状态字段默认 1，创建时间默认当前时间。

第五，外键约束（Foreign Key）。这个我需要多说两句，因为它最容易引发争议。

外键的作用是确保两张表之间的引用完整性。比如订单表的user_id指向用户表的id，如果用户被删，外键可以阻止删除或者级联删除订单。概念上很完美，但互联网业务中绝大多数团队会主动放弃外键。原因在于：外键会让每次写入都触发对父表的额外检查，高并发场景下性能损失明显；大厂普遍采用分库分表，物理层面的外键根本没法跨库生效；应用层做逻辑校验已经足够应对绝大多数场景。

所以我的建议是：业务初始阶段，外键逻辑在应用层实现，但如果你的系统并发不高、数据一致性要求极其严格（比如财务类系统），那么外键也不失为一种简单可靠的手段。关键是意识到有这层机制，而不是完全无知地裸奔。

3.3 查看表结构的三板斧

表建完之后，怎么确认建得没问题？三个命令要记牢。

第一板斧，看当前库下的所有表：

SHOW TABLES;

第二板斧，看表的建表语句：

SHOW CREATE TABLE user\G

注意结尾的\G，它能把结果竖排显示，比默认横排表格在字段多的时候清晰得多。这个命令在排查表结构问题时比DESC更全面，因为你能看到完整的引擎、字符集、注释、索引定义。

第三板斧，看表的字段明细：

DESC user;

或者写全一点：

DESCRIBE user;

它会列出字段名、类型、是否允许 NULL、键类型、默认值、备注等。日常调试时用DESC最顺手，信息量足够。

查看已存在的表结构，还有个更贴近业务的切入点，就是查看数据库里所有表的信息，比如用：

SELECT TABLE_NAME, TABLE_ROWS, DATA_LENGTH FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'shop';

information_schema是 MySQL 自带的“元数据仓库”，保存着所有数据库、表、字段的信息。学会查它，你就迈入中级玩家行列了。

4. 表结构的修改与维护

4.1 修改表名与字符集

业务迭代后，表名可能会变得不合适，需要重命名。语法是：

RENAME TABLE old_name TO new_name;

也可以使用 ALTER 的写法：

ALTER TABLE old_name RENAME TO new_name;

两种效果一样，我更推荐RENAME TABLE，因为它还支持一次改多张表：

RENAME TABLE a TO b, c TO d;

在需要原子性切换两张表名（比如发布新表、下线旧表）时很管用。这里提一个经验：线上执行表重命名之前，务必检查有没有代码还在引用旧表名，以及权限配置里有没有针对旧表名的授权。改完表名后，所有以旧表名命名的授权都会被悬空，新表名需要重新授权。

修改表的字符集和排序规则，常见写法：

ALTER TABLE mytable CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

这里有一个重要的差别：ALTER TABLE mytable DEFAULT CHARACTER SET utf8mb4只修改表的默认字符集，不会修改已有字段的字符集；CONVERT TO CHARACTER SET会把表中所有字符型字段的数据一并转换。所以要做全局字符集升级，必须用CONVERT TO。这个命令在很多历史库从 latin1 迁移到 utf8mb4 时非常关键。

需要提醒的是，大表执行这类 ALTER 会锁表或长时间占用资源，生产环境尽量在低峰期操作，或者使用后续版本支持的在线 DDL 方式。这不是新手阶段要考虑的最高优事项，但要知道“改表”不是免费的。

4.2 字段级别的增删改

字段级别的修改是 ALTER TABLE 用得最多的场景。我按常用频率排个序。

新增字段：

ALTER TABLE user ADD COLUMN nickname VARCHAR(30) DEFAULT NULL COMMENT '昵称' AFTER username;

AFTER username表示把这个字段加在 username 字段之后。如果不指定位置，默认加在最后。字段位置对功能没影响，但查询结果列顺序和可读性会有影响，所以最好按业务相关性排。

修改字段类型：

ALTER TABLE user MODIFY COLUMN phone VARCHAR(20) COMMENT '联系电话';

MODIFY会直接覆盖原来的字段定义。这里容易踩坑：如果你没有把原有属性写全，比如原来有NOT NULL，现在写 MODIFY 时忘了加，字段的可空性就变了。用MODIFY必须把你想要保留的属性全部重新写一遍。这也是新手常掉进去的坑。

修改字段名：

ALTER TABLE user CHANGE COLUMN phone mobile VARCHAR(20) COMMENT '手机号';

CHANGE和MODIFY的区别在于，CHANGE可以同时改字段名，所以参数里要写两个字段名：旧名和新名。如果你只是想改类型，用MODIFY；想改名，必须用CHANGE。

删除字段：

ALTER TABLE user DROP COLUMN nickname;

删除字段后，该字段上的索引、约束也会随之消失，如果别的业务代码还在引用这个字段，就会直接报错。所以删除字段前，最好全局搜一遍代码。

4.3 清空数据与删除表

删除整个表：

DROP TABLE IF EXISTS user;

和DROP DATABASE一样，这是不可逆操作，表结构和数据一起消失。执行前一定要SHOW CREATE TABLE确认表名，最好再做一次备份。

清空表中所有数据但保留表结构，有三种方式，这里必须把它们的区别讲清楚。

DELETE FROM user;

逐行删除，支持事务，删除慢，但如果有 WHERE 条件，可以先删一部分数据。注意，DELETE后表内的自增计数器不会重置，比如原来有 10 条记录，删除后再插入，ID 从 11 开始。

TRUNCATE TABLE user;

直接重建表空间，速度快得多，并且会重置自增计数器，下一条记录 ID 又从 1 开始。它不支持 WHERE，是一次性清空全部数据。如果表不重要且确认要全清，TRUNCATE是最高效的方式。

DROP TABLE user;

连表和结构都不要了。

三者怎么选？记住了：保留结构只清数据，能接受自增重置，就用TRUNCATE；需要按条件删一部分，或需要事务回滚，就用DELETE；表和结构彻底不要了，就用DROP。

表结构的变更在项目里很常见，但如果每次都是人工登录服务器敲 ALTER，既容易出错也不好追溯。如果你已经能用 SQL 熟练完成前面这些操作，下一步就可以考虑把表结构变更脚本纳入版本管理，让每次 DDL 都有记录可查。这算是架构思维的一个雏形了。

5. 实操避坑指南与高频命令速查

5.1 常见报错与原因对照

把这些年见过的报错整理成一个速查表，方便你以后对照。

比如Duplicate entry这个报错，新手经常会不明所以。它本质上是唯一约束（UNIQUE KEY）被触发了。可能是插入了重复的用户名、重复的手机号，或者批量导入数据时主键冲突。解决思路是找重复，可以通过SELECT分组查询排查。这个报错在数据迁移时尤其频繁，因为目标表里往往已经有历史数据，而源表可能数据质量并不好。

Incorrect string value这个报错在早期库表没建好的系统里就是噩梦。如果你创建库表时没注意字符集，表默认是latin1，往里面插中文就报这个错。解决方向：建库建表时统一utf8mb4；已存在的表用ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4转换。千万别只改客户端连接编码，那只是治标不治本。

5.2 字符集乱码问题排查

乱码是中文用户绕不开的话题。我给你一个系统排查思路，按顺序检查四层。

第一层，客户端连接编码。命令行登录后，执行：

SHOW VARIABLES LIKE 'character_set_client'; SHOW VARIABLES LIKE 'character_set_connection';

如果显示的不是utf8mb4，那么你输入的中文 SQL 在到达服务器时就已经变形了。可以在登录时显式指定编码：

mysql -u root -p --default-character-set=utf8mb4

或者在连接后执行：

SET NAMES utf8mb4;

第二层，数据库和表的字符集。用：

SHOW CREATE DATABASE 库名; SHOW CREATE TABLE 表名;

检查是否存在哪一层还是latin1。库、表的字符集可以不同，但最终决定字段存什么编码的是字段级别字符集。一般情况下，你建库的时候指定utf8mb4，表和字段都会默认继承。

第三层，客户端工具显示。如果你用图形化工具连数据库，工具自身也要设置字符集。比如老版本的连接配置里，编码不是 UTF-8，你在工具里能看到中文，但用命令行查还是乱码，这类问题多在工具侧。

第四层，数据文件的真实存储。如果你已经导入了乱码数据，光改前面的配置是救不回历史数据的。除非源数据文件重新导入且编码正确，否则乱码数据只能清理重导。这也是为什么我一直强调：字符集在库表创建时就定好，后期补救代价极高。

5.3 实操避坑清单：每条都是血的教训

最后的实操避坑，我总结几条只能靠经验积累才知道的教训。

第一条，删库删表先备份。哪怕你是本地环境，也可能有你想不到的增量数据。最稳妥的做法是操作前用mysqldump快速备份：

mysqldump -u root -p shop > shop_backup.sql

在生产环境，这句话的含金量你自己体会。备份固然重要，但更关键的是恢复演练。光备份了没试过恢复，等于没备份。我见过太多团队备份脚本跑了半年，真到需要恢复时才发现备份文件是坏的或者不完整。至少每季度做一次完整恢复演练，把备份文件导入一个全新的库，验证数据完整性。

第二条，批量操作前先 SELECT 预览。尤其是写DELETE或UPDATE语句时，先把 WHERE 条件放到 SELECT 里跑一遍，确认命中数据和预期一致，再真正执行变更。比如：

SELECT * FROM user WHERE status = 0; -- 确认无误后执行 DELETE FROM user WHERE status = 0;

这一步能拦住大部分因为 WHERE 条件写错导致的大批量误删。

第三条，给表名和字段名加反引号。虽然现在大多数数据库名和表名不会和关键字撞车，但像user、order、group这种高频词，在某些版本里就是关键字或者保留字。加反引号是零成本的保险。另外建议字段名用蛇形命名，全小写，单词间用下划线分隔，这样在 Linux 和 Windows 之间迁移不会有大小写敏感的问题。

第四条，版本管理表结构。把建表语句、ALTER 语句保存成 .sql 文件，纳入版本管理。当项目上线后，所有表结构的变更都通过脚本执行而不是手工操作，这样协作的同事也能追踪变更历史。这是从小白向正规军进阶的关键一步。

第五条，权限最小化。日常开发不要一直用 root 账号连库。创建一个只对自己业务库有权限的账号：

CREATE USER 'app_user'@'localhost' IDENTIFIED BY 'strong_password'; GRANT SELECT, INSERT, UPDATE, DELETE ON shop.* TO 'app_user'@'localhost'; FLUSH PRIVILEGES;

这样能大大降低误操作影响面，也符合团队安全规范。数据库权限这件事越早意识到越主动，等你带过了项目、处理过线上事故，就会认同这个建议的价值。

6. 最后说点个人体会

数据库和表的基本操作，看起来只是几条命令，但它背后隐含的是对数据模型、存储引擎、约束机制的整体理解。我自己从只会用图形界面工具，到能熟练在命令行里完成全套库表操作，花了大概两周时间。那段时间我每天在一个临时实例上反复建表、删表、改表，故意给自己制造各种报错，然后逐个解决。这个过程虽然有些枯燥，但收益是长期的——之后学索引优化、事务隔离、复杂查询，都因为对底层结构烂熟于心而变得顺畅得多。

如果你才刚开始接触 MySQL，不需要背下所有命令，把这篇文章里的语句抄下来，实际在本地环境敲两遍，不要复制粘贴，每个字都亲手打出来，你很快就会发现哪些地方容易出错、哪些细节容易忽略。等你能不看参考文档独立建出用户表、商品表、订单表各一张，你的第一步就算真正迈出去了。