MySQL 数据库（三）：表级操作实战：增删查改全实例演示 + 企业实操红线规范

在 MySQL 的日常开发与运维中，库级操作是最基础也最容易踩坑的环节。很多新手建库时不指定字符集、不关注校验规则，到了生产环境会出现中文乱码、查询大小写异常等问题；更有高危操作误删库导致数据丢失。本文通过完整实例，带你吃透 MySQL 数据库的创建、查看、修改、删除全流程操作，最后附上企业内必须遵守的操作规范。
观众老爷们大家好这里是邪修KING的独家频道 本文属于系列MySQL ------数据库管理 一起学MySQL的小伙伴可订阅专栏： MySQL数据库篇 ## 一、创建数据库（增）：3 个常用场景实例

创建数据库使用CREATE DATABASE命令，可按需指定字符集和校验规则。企业场景中建库建议显式指定配置，避免依赖环境默认值引发跨环境差异。

实例 1：创建默认配置的数据库

创建名为db1的数据库，不指定任何参数，直接使用系统默认字符集和校验规则。

复制代码

CREATE DATABASE db1;

说明：不同 MySQL 版本默认字符集有差异，5.x 早期版本默认latin1，5.7 部分版本默认utf8，8.0 默认utf8mb4。不指定字符集是最不推荐的写法，跨环境部署极易出现乱码。

实例 2：指定字符集创建数据库

创建使用utf8字符集的数据库db2，确保支持中文数据存储。

复制代码

CREATE DATABASE db2 CHARSET=utf8;

实例 3：指定字符集 + 校验规则创建数据库

创建使用utf8字符集，且校验规则为utf8_general_ci的数据库db3。

复制代码

CREATE DATABASE db3 CHARSET=utf8 COLLATE=utf8_general_ci;

重点实测：校验规则对数据的影响

校验规则直接决定了字符串的大小写是否敏感 和排序规则，最常用的两种规则差异极大：

utf8_general_ci：ci 代表 case insensitive，不区分大小写
utf8_bin：二进制比对，严格区分大小写

我们通过两个测试库直观对比效果：

测试 1：不区分大小写（utf8_general_ci）

bash 复制代码

-- 创建测试库
CREATE DATABASE test1 COLLATE=utf8_general_ci;
USE test1;
-- 创建测试表并插入大小写数据
CREATE TABLE person(name VARCHAR(20));
INSERT INTO person VALUES('a'),('A'),('b'),('B');

查询name='a'的结果：

bash 复制代码

SELECT * FROM person WHERE name='a';

输出结果：

bash 复制代码

+------+
| name |
+------+
| a    |
| A    |
+------+
2 rows in set (0.01 sec)

不区分大小写模式下，小写a和大写A都会被匹配到。

排序效果：

bash 复制代码

SELECT * FROM person ORDER BY name;

结果会按字母顺序合并大小写排序：a、A、b、B。

测试 2：区分大小写（utf8_bin）

bash 复制代码

CREATE DATABASE test2 COLLATE=utf8_bin;
USE test2;
CREATE TABLE person(name VARCHAR(20));
INSERT INTO person VALUES('a'),('A'),('b'),('B');

同样查询name='a'：

bash 复制代码

SELECT * FROM person WHERE name='a';

输出结果：

bash 复制代码

+------+
| name |
+------+
| a    |
+------+
1 row in set (0.01 sec)

严格区分大小写，只会匹配到完全一致的小写a。

排序效果：

bash 复制代码

SELECT * FROM person ORDER BY name;

结果按 ASCII 码值排序：大写字母在前，小写在后，即A、B、a、b。

企业提示：建库前一定要和业务确认是否需要区分大小写，比如用户名、唯一编码类字段一般需要区分，昵称、搜索类字段一般不需要。一旦建库完成再修改校验规则，需要全量迁移数据，成本极高。

二、查看数据库（查）：4 个常用查询命令

日常操作中，我们经常需要查看已有数据库、确认建库语句、核对字符集配置。

实例 1：查看所有数据库

bash 复制代码

SHOW DATABASES;

执行后会列出当前 MySQL 实例中全部数据库，包括系统自带的mysql、information_schema、performance_schema等系统库。

实例 2：查看某数据库的完整建库语句

查看mytest数据库的创建语句，确认其字符集、校验规则配置：

bash 复制代码

SHOW CREATE DATABASE mytest;

输出示例：

bash 复制代码

+----------+---------------------------------------------------------------+
| Database | Create Database                                               |
+----------+---------------------------------------------------------------+
| mytest   | CREATE DATABASE `mytest` /*!40100 DEFAULT CHARACTER SET utf8 */ |
+----------+---------------------------------------------------------------+

说明：

数据库名的反引号```是为了避免库名和 SQL 关键字冲突；

/*!40100 ... */不是注释，表示 MySQL 版本≥4.01 时才执行这条语句，属于版本兼容语法。

实例 3：查看系统默认字符集与校验规则

bash 复制代码

-- 查看当前默认字符集
SHOW VARIABLES LIKE 'character_set_database';
-- 查看当前默认校验规则
SHOW VARIABLES LIKE 'collation_database';

实例 4：查看系统支持的所有字符集 / 校验规则

bash 复制代码

-- 查看所有支持的字符集
SHOW CHARSET;

-- 查看所有支持的校验规则
SHOW COLLATION;

三、修改数据库（改）：字符集修改实例

修改数据库主要是调整字符集和校验规则，使用ALTER DATABASE命令。

实例：将 mytest 数据库字符集改为 gbk

bash 复制代码

ALTER DATABASE mytest CHARSET=gbk;

执行成功提示：Query OK, 1 row affected (0.00 sec)

修改后再次查看建库语句验证：

bash 复制代码

SHOW CREATE DATABASE mytest;

输出中字符集已更新为 gbk：

bash 复制代码

+----------+--------------------------------------------------------------+
| Database | Create Database                                              |
+----------+--------------------------------------------------------------+
| mytest   | CREATE DATABASE `mytest` /*!40100 DEFAULT CHARACTER SET gbk */ |
+----------+--------------------------------------------------------------+

⚠️ 重要警告：

修改数据库字符集只会影响后续新建的表 ，库中已有的数据表字符集不会同步改变。如果库中已有历史数据，强行修改会导致历史数据乱码。企业生产环境禁止直接修改已有数据库的字符集，必须先制定完整的数据迁移方案并通过评审。

四、删除数据库（删）：高危操作演示

删除数据库会级联删除库内所有表、所有数据，且无法通过 SQL 回滚恢复，是最高危的数据库操作之一。

基础语法

bash 复制代码

-- 直接删除，库不存在时会报错
DROP DATABASE db_name;

-- 推荐写法：库存在才执行删除，不存在也不报错
DROP DATABASE IF EXISTS db_name;

执行效果

删除命令执行后：

MySQL 中无法再查询到该数据库
磁盘上对应的数据库文件夹被直接删除
库内所有数据表、索引、数据全部级联删除

企业红线：生产环境删除数据库必须提前做全量备份、双人复核、走正式审批流程，严禁私自执行删库操作。

五、企业必备：数据库备份与恢复

线上数据无价，任何高危操作前都必须备份。mysqldump是 MySQL 最常用的逻辑备份工具。

1. 备份单个数据库

退出 MySQL 终端，在系统命令行执行：

bash 复制代码

mysqldump -P3306 -u root -p密码 -B mytest > /data/mytest.sql

-B参数：会在备份文件中生成建库语句，恢复时无需手动创建空库

备份的.sql文件包含了建库、建表、插入数据的完整 SQL 语句

2. 恢复数据库

进入 MySQL 终端，执行 source 命令加载备份文件：

bash 复制代码

SOURCE /data/mytest.sql;

3. 其他常用备份场景

备份单张 / 多张表（不加 - B，库名后直接跟表名）

bash 复制代码

mysqldump -u root -p mytest student course > /data/mytest_table.sql

同时备份多个数据库

bash 复制代码

mysqldump -u root -p -B db1 db2 db3 > /data/multi_db.sql

注意：如果备份时没加-B参数，恢复时必须先手动创建空数据库，再use进入该库，最后执行 source 命令恢复数据。

六、运维排查：查看数据库连接情况

当数据库响应变慢、疑似被入侵时，用这条命令查看当前所有客户端连接：

bash 复制代码

SHOW PROCESSLIST;

输出示例：

bash 复制代码

+----+------+-----------+------+---------+------+-------+------------------+
| Id | User | Host      | db   | Command | Time | State | Info             |
+----+------+-----------+------+---------+------+-------+------------------+
| 2  | root | localhost | test | Sleep   | 1386 | NULL  | NULL             |
| 3  | root | localhost | NULL | Query  | 0    | NULL  | show processlist |
+----+------+-----------+------+---------+------+-------+------------------+

可以看到每个连接的用户、来源主机、操作的数据库、执行的命令、运行时长。

如果出现陌生 IP、陌生用户的连接，可能是数据库被非法入侵
如果有大量 Sleep 状态的长连接，可能存在应用连接泄漏
如果有 Time 值很大的 Query，说明存在慢 SQL 拖垮数据库性能

七、企业内数据库操作红线规范

最后强调企业开发、运维中必须遵守的操作准则，从流程上避免数据事故：

禁止随意修改库表结构与表名：任何表结构变更、表重命名、库字符集修改，必须提交技术评审，制定回滚方案，在业务低峰期执行。
删库删表必须备份 + 复核：生产环境删除操作前必须完成全量备份，操作时双人在场复核命令，确认无误再执行。
禁止用 root 账号直接操作业务：业务开发、日常运维使用专属权限账号，遵循最小权限原则，禁止超级账号直接操作业务数据。
建库即确定字符集与校验规则：字符集、校验规则在创建库时就按业务规范指定，后续禁止修改，避免引发历史数据乱码。
高危操作必须留痕：生产环境所有 DDL 操作、删改操作必须有审批记录、操作日志，禁止私下执行未备案的高危操作。