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）

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

查询name='a'的结果：

SELECT * FROM person WHEREname='a';

输出结果：

+------+|name|+------+|a||A|+------+2rowsinset(0.01sec)

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

排序效果：

SELECT * FROM person ORDER BY name;

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

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

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

同样查询name='a'：

SELECT * FROM person WHEREname='a';

输出结果：

+------+|name|+------+|a|+------+1rowinset(0.01sec)

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

排序效果：

SELECT * FROM person ORDER BY name;

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

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

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

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

实例 1：查看所有数据库

SHOW DATABASES;

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

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

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

SHOW CREATE DATABASE mytest;

输出示例：

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

说明：

• 数据库名的反引号```是为了避免库名和 SQL 关键字冲突；
• /*!40100 ... */不是注释，表示 MySQL 版本≥4.01 时才执行这条语句，属于版本兼容语法。

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

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

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

-- 查看所有支持的字符集 SHOW CHARSET;-- 查看所有支持的校验规则 SHOW COLLATION;

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

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

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

ALTER DATABASE mytestCHARSET=gbk;

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

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

SHOW CREATE DATABASE mytest;

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

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

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

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

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

基础语法

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

执行效果

删除命令执行后：

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

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

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

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

1. 备份单个数据库

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

mysqldump-P3306-uroot -p密码-Bmytest>/data/mytest.sql

• -B参数：会在备份文件中生成建库语句，恢复时无需手动创建空库
• 备份的.sql文件包含了建库、建表、插入数据的完整 SQL 语句

2. 恢复数据库

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

SOURCE /data/mytest.sql;

3. 其他常用备份场景

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

mysqldump-uroot-pmytest student course>/data/mytest_table.sql

• 同时备份多个数据库

mysqldump-uroot-p-Bdb1 db2 db3>/data/multi_db.sql

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

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

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

SHOW PROCESSLIST;

输出示例：

+----+------+-----------+------+---------+------+-------+------------------+|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 拖垮数据库性能

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

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

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