【MySQL数据库基础】（三）MySQL 库的核心操作全解析：创建、修改、备份一条龙搞定

Ne0inhk

— 16 min read
【MySQL数据库基础】（三）MySQL 库的核心操作全解析：创建、修改、备份一条龙搞定

前言

        在 MySQL 的学习和实战中，数据库（库）的操作是最基础也是最核心的环节，无论是项目开发、数据管理还是运维维护，都绕不开库的创建、配置、修改、备份等一系列操作。很多刚接触 MySQL 的小伙伴容易在字符集、校验规则、备份恢复这些细节上踩坑，今天这篇文章就结合实战案例，把 MySQL 库的全套操作讲透，从基础语法到高级技巧，从避坑指南到实战演示，让你一文掌握 MySQL 库操作的精髓！

一、创建数据库：基础语法与个性化配置

        创建数据库是操作 MySQL 的第一步，看似简单的一句命令，背后却藏着字符集、校验规则的关键配置，选对配置能让后续的开发和数据管理少走很多弯路。

1. 核心创建语法

        MySQL 中创建数据库的官方语法如下，其中大写部分为关键字，中括号[]内的为可选项，也是实际开发中需要重点关注的部分：

CREATE DATABASE [IF NOT EXISTS] db_name [create_specification [, create_specification] ...];

        其中create_specification用于配置数据库的核心属性，主要包含两项：

[DEFAULT] CHARACTER SET charset_name; -- 指定数据库字符集 [DEFAULT] COLLATE collation_name; -- 指定字符集的校验规则

        这里有两个关键的小细节需要注意：

IF NOT EXISTS：可选但建议必加，避免创建已存在的数据库时抛出错误，让 SQL 语句更健壮；DEFAULT关键字：可省略，不影响功能，写出来会让语法更清晰，明确是设置默认属性。

2. 实战创建案例

        结合语法，我们分三种常见场景演示数据库的创建，覆盖从简单到个性化配置的全部情况。

场景 1：基础创建，使用系统默认配置

        如果创建时不指定字符集和校验规则，MySQL 会使用默认的字符集utf8，校验规则utf8_general_ci，这也是开发中最常用的默认配置：

-- 创建名为db1的数据库，使用默认字符集和校验规则 create database db1;

场景 2：指定字符集，使用默认校验规则

        如果需要自定义字符集，可通过charset关键字指定，校验规则会沿用该字符集的默认值：

-- 创建名为db2的数据库，指定字符集为utf8 create database db2 charset=utf8;

场景 3：同时指定字符集和校验规则

        针对有特殊需求的场景（比如区分大小写查询），可以同时指定字符集和对应的校验规则：

-- 创建名为db3的数据库，指定utf8字符集和utf8_general_ci校验规则 create database db3 charset=utf8 collate utf8_general_ci;

二、字符集与校验规则：MySQL 库的灵魂配置

        字符集和校验规则是 MySQL 数据库的核心属性，字符集决定了数据库能存储哪些语言的字符（比如 utf8 支持中文，latin1 不支持中文），校验规则则决定了数据的查询、排序规则（比如是否区分大小写）。很多开发中的乱码、查询结果不符合预期问题，根源都是这两个配置出了问题。

1. 查看系统默认配置

        想要知道当前 MySQL 的默认字符集和校验规则，可通过以下两条 SQL 语句查询，这是开发前的必备操作，避免因默认配置不符导致问题：

-- 查看系统默认字符集 show variables like 'character_set_database'; -- 查看系统默认校验规则 show variables like 'collation_database';

2. 查看 MySQL 支持的所有字符集和校验规则

        MySQL 支持多种字符集和对应的校验规则，可通过以下语句查看完整列表，根据需求选择：

-- 查看MySQL支持的所有字符集 show charset; -- 查看MySQL支持的所有校验规则 show collation;

        关键提醒：utf8 是目前开发中的主流字符集，支持多语言字符，也是 MySQL 的默认选择，除非有特殊历史需求，否则不建议使用 latin1 等不支持中文的字符集。

3. 校验规则的实际影响：区分 / 不区分大小写

        校验规则的核心作用体现在数据查询和结果排序上，最典型的就是utf8_general_ci（不区分大小写）和utf8_bin（区分大小写）的区别，我们通过实战案例直观感受。

案例 1：使用 utf8_general_ci（不区分大小写）

-- 创建数据库test1，指定校验规则为utf8_general_ci 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'的数据 select * from person where name='a'; -- 按name排序 select * from person order by name;

查询结果：查询name='a'时，会同时返回a和A；排序时不区分大小写，按字母顺序排列。

案例 2：使用 utf8_bin（区分大小写）

-- 创建数据库test2，指定校验规则为utf8_bin create database test2 collate utf8_bin; use test2; -- 创建测试表并插入相同数据 create table person(name varchar(20)); insert into person values('a'),('A'),('b'),('B'); -- 查询name='a'的数据 select * from person where name='a'; -- 按name排序 select * from person order by name;

        查询结果：查询name='a'时，只返回a；排序时区分大小写，大写字母会排在前面（A、B 在前，a、b 在后）。

        核心结论：如果是用户信息、用户名等需要区分大小写的场景，可使用utf8_bin；如果是普通业务数据，建议使用utf8_general_ci，提升查询的灵活性。

三、操纵数据库：查看、修改、删除的全套操作

        创建数据库后，日常的操纵操作主要包括查看数据库信息、修改数据库配置、删除无用数据库，这部分操作语法简单，但需要注意操作的安全性（尤其是删除）。

1. 查看数据库：掌握当前 MySQL 的库信息

场景 1：查看 MySQL 中所有的数据库

        这条语句是最常用的，能快速获取当前 MySQL 服务中存在的所有数据库，包括系统库和自定义库：

show databases;

场景 2：查看指定数据库的创建语句

        想要知道某个数据库的详细配置（比如字符集、校验规则），可通过该语句查询，能看到数据库的完整创建语法，包括 MySQL 的版本兼容配置：

-- 查看mytest数据库的创建语句 show create database mytest;

查询结果示例：

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

        这里有两个关键细节需要理解：

数据库名的反引号`：用于防止数据库名与 MySQL 关键字重复，是良好的编码习惯；/*!40100 DEFAULT CHARACTER SET utf8 */：这不是注释！表示当前 MySQL 版本大于 4.01 时，自动执行该语句，实现版本兼容。

2. 修改数据库：仅修改字符集和校验规则

        MySQL 中对数据库的修改仅支持字符集和校验规则的修改，不支持修改数据库名（如果需要修改库名，建议新建库后迁移数据），核心语法如下：

ALTER DATABASE db_name [alter_spacification [,alter_spacification]...]; -- 其中alter_spacification与创建时一致 [DEFAULT] CHARACTER SET charset_name; [DEFAULT] COLLATE collation_name;

实战案例：修改数据库的字符集

        将mytest数据库的字符集从默认的utf8修改为gbk，并验证修改结果：

-- 修改mytest的字符集为gbk alter database mytest charset=gbk; -- 验证修改结果 show create database mytest;

修改后结果：

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

3. 删除数据库：谨慎操作，避免数据丢失

        删除数据库是高危操作，执行后数据库对应的文件夹会被彻底删除，库内的所有表和数据也会被级联删除，且无法恢复，核心语法如下：

DROP DATABASE [IF EXISTS] db_name;

关键提醒：

IF EXISTS：必加！避免删除不存在的数据库时抛出错误；生产环境中，禁止直接执行删除数据库的语句，如需删除，需先做数据备份，且经过审批；开发环境中，删除前确认数据库无用，避免误删开发数据。

执行结果：

MySQL 中无法再查询到该数据库；数据库对应的物理文件夹被删除；库内的所有表、数据被级联删除。

四、数据库的备份与恢复：数据安全的最后一道防线

        数据是项目的核心资产，无论是开发环境还是生产环境，数据库的备份都是必备操作。MySQL 提供了mysqldump工具实现备份，通过source命令实现恢复，支持单库、单表、多库等多种备份场景，我们逐一讲解。

1. 备份的核心工具：mysqldump

    mysqldump是 MySQL 自带的备份工具，基于命令行执行（需退出 MySQL 连接，在 bash/CMD 中操作），核心语法如下：

# 基础语法：备份单个数据库 mysqldump -P端口号 -u用户名 -p密码 -B 数据库名 > 备份文件存储路径/备份文件名.sql

        参数说明：

-P：指定 MySQL 的端口号，默认 3306，可省略；-u：指定连接 MySQL 的用户名；-p：指定连接 MySQL 的密码，密码与-p之间无空格；-B：关键参数，用于备份数据库，包含数据库的创建语句；>：重定向符号，将备份的内容写入指定的 sql 文件。

2. 多场景备份实战

场景 1：备份单个完整数据库

        将mytest数据库备份到 D 盘根目录，备份文件名为mytest.sql（MySQL 端口 3306，用户名 root，密码 123456）：

# bash/CMD中执行，退出MySQL连接 mysqldump -P3306 -u root -p123456 -B mytest > D:/mytest.sql

        备份后的sql文件包含了数据库创建语句、表创建语句、数据插入语句，相当于保存了数据库的完整镜像。

场景 2：备份数据库中的单个 / 多个表

        如果不需要备份整个数据库，仅需备份部分表，可在数据库名后指定表名，多个表名用空格分隔：

# 备份mytest数据库中的person表和user表 mysqldump -u root -p123456 mytest person user > D:/mytest_tables.sql

场景 3：同时备份多个数据库

        通过-B参数后跟多个数据库名，可实现多库批量备份，适合整库迁移的场景：

# 同时备份mytest、db1、db2三个数据库 mysqldump -u root -p123456 -B mytest db1 db2 > D:/multi_db.sql

3. 数据库恢复实战：source 命令

        恢复数据库需在 MySQL 连接中执行，核心命令是source，通过读取备份的sql文件，自动执行其中的 SQL 语句，实现数据库、表、数据的恢复，语法如下：

-- MySQL中执行，恢复指定备份文件 source 备份文件的绝对路径;

实战案例：恢复 mytest 数据库

-- 登录MySQL后执行 source D:/mytest.sql;

4. 备份与恢复的关键注意事项

        这部分是避坑重点，很多小伙伴恢复失败都是因为忽略了这些细节：

-B 参数的重要性：如果备份时未加-B参数，备份文件中会缺少数据库的创建语句，恢复时需要先手动创建空数据库，并使用use 数据库名;指定数据库，再执行source命令；路径问题：备份和恢复时建议使用绝对路径，避免相对路径导致的文件找不到问题；权限问题：执行mysqldump的用户需要有数据库的查询权限，恢复时的用户需要有数据库的创建、插入权限；编码问题：备份文件的编码与数据库字符集保持一致，避免恢复后出现乱码；生产环境备份策略：生产环境建议采用定时自动备份（比如 crontab 定时任务），并将备份文件存储在独立的服务器，避免原服务器故障导致备份文件丢失。

五、查看数据库连接情况：排查数据库卡顿与入侵

        在实际开发和运维中，经常会遇到数据库卡顿、响应慢的问题，甚至可能出现数据库被非法入侵的情况，MySQL 提供了show processlist命令，能实时查看当前的数据库连接情况，快速定位问题。

1. 核心语法

-- 查看当前所有的MySQL连接 show processlist;

2. 结果解析

        执行后会返回当前所有的连接信息，核心字段说明：

字段含义
Id连接的唯一标识
User连接数据库的用户名
Host连接的客户端 IP 和端口
db该连接正在使用的数据库
Command连接的当前状态（Sleep/Query 等）
Time状态持续的时间（秒）
State连接的详细状态
Info该连接正在执行的 SQL 语句

3. 实战应用场景

排查数据库卡顿：如果数据库响应慢，执行show processlist后，若发现大量Query状态的连接，且Time数值很大，说明有慢 SQL 正在执行，可通过Info字段查看具体 SQL，进行优化；排查非法入侵：如果发现User和Host字段中有陌生的用户名或非内网的 IP 地址，说明数据库可能被非法入侵，需立即修改数据库密码，关闭高危端口；释放无效连接：如果发现大量Sleep状态的连接，且Time数值很大，说明存在大量无效连接，可通过kill 连接Id;命令释放，也可通过配置 MySQL 的超时参数自动释放。

示例：杀死 Id 为 2 的无效连接

kill 2;

六、MySQL 库操作的核心避坑指南与最佳实践

        通过以上内容，我们掌握了 MySQL 库的全套操作，最后总结一些实战中的避坑指南和最佳实践，让你的操作更规范、更安全。

1. 核心避坑点

创建数据库必加 IF NOT EXISTS：避免重复创建抛出错误，让 SQL 更健壮；禁止直接删除生产库：删除前先备份，生产环境建议做删除权限管控；备份必加 - B 参数：避免恢复时缺少库创建语句，导致恢复失败；字符集优先选择 utf8：避免中文乱码，不建议使用 latin1 等小众字符集；查看连接时关注陌生 IP：及时发现数据库的非法入侵行为。

2. 最佳实践

关键字大写，库名 / 表名小写：符合 MySQL 的编码规范，提升 SQL 的可读性；库名 / 表名使用反引号：防止与 MySQL 关键字重复；定时备份数据库：生产环境采用 “本地备份 + 异地备份” 的双重策略；限制数据库用户权限：遵循最小权限原则，开发用户仅赋予查询、插入、更新权限，不赋予删除、创建库的权限；定期查看数据库连接：及时释放无效连接，优化慢 SQL，保证数据库性能。

总结

        MySQL 库的操作是 MySQL 入门的基础，也是后续表、数据、索引操作的前提，本文从创建数据库入手，讲解了字符集和校验规则的核心配置，再到查看、修改、删除的日常操纵，最后重点讲解了备份恢复和连接排查的实战技巧，覆盖了开发和运维中最常用的所有场景。

        其实 MySQL 的库操作并不复杂，关键在于把字符集、校验规则、-B 参数这些细节掌握到位，同时养成规范编码、定时备份、谨慎删除的良好习惯。掌握这些内容后，你就能轻松应对日常的数据库管理工作，为后续的 MySQL 进阶学习打下坚实的基础。

        后续我会继续更新 MySQL 表的操作、数据的 CRUD、索引优化等内容，关注我，一起从 MySQL 入门到实战！

Read more

Flutter 三方库 opml 的鸿蒙化适配指南 - 支持大容量订阅源解析、符合 OPML 2.0 规范与 RSS 管理器核心适配

Flutter 三方库 opml 的鸿蒙化适配指南 - 支持大容量订阅源解析、符合 OPML 2.0 规范与 RSS 管理器核心适配

欢迎加入开源鸿蒙跨平台社区：https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 opml 的鸿蒙化适配指南 - 支持大容量订阅源解析、符合 OPML 2.0 规范与 RSS 管理器核心适配 前言 在进行 Flutter for OpenHarmony 的阅读类、播客类或 RSS 订阅类应用开发时，支持标准的 OPML（Outline Processor Markup Language）导入与导出是必选功能。opml 库是一个专门用于解析和生成 OPML 文件的 Dart 库。本文将探讨如何在鸿蒙系统下，利用该库高效管理用户的订阅树结构。 一、原理解析 / 概念介绍 1.1 基础原理 OPML 本质上是一种基于

By Ne0inhk
【高级终端Termux】在安卓手机/平板上使用Termux 搭建 Debian 环境并运行 PC 级 Linux 应用教程（含安装WPS,VS Code）

【高级终端Termux】在安卓手机/平板上使用Termux 搭建 Debian 环境并运行 PC 级 Linux 应用教程（含安装WPS,VS Code）

Termux 搭建 Debian 环境并运行 PC 级 Linux 应用教程 一、前言 1. 背景 众所周知，最新搭载澎湃OS和鸿蒙OS的平板都内置了PC级WPS，办公效率直接拉满（板子终于从“泡面盖”升级为“生产力”了）。但问题来了：如果不是这两个系统，难道我们只能继续用平板盖泡面吗？当然不是！折腾了很长时间后，总算找到了一个好玩的东西：高级终端Termux 。现在，不仅能随时随地用WPS改文档，还能VSCode优雅地敲代码，再也不用背着电脑乱跑了。 由于每次搭建环境时都要去不同的平台找不同功能，有时还找不到，所以我决定自己写一篇博客，方便自己以后再搭建时直接“Ctrl C + Ctrl V”，顺便分享给有同样需求的小伙伴们。话不多说，直接开整！ 2. 准备工作 * 一部安卓手机：性能越好，折腾起来越顺畅。 * Termux 应用： 不想去F-droid下载的看过来

By Ne0inhk
Flutter 三方库 filterator 的鸿蒙化适配指南 - 掌握声明式数据流过滤技术、助力鸿蒙应用构建极速且易维护的复杂列表筛选逻辑

Flutter 三方库 filterator 的鸿蒙化适配指南 - 掌握声明式数据流过滤技术、助力鸿蒙应用构建极速且易维护的复杂列表筛选逻辑

欢迎加入开源鸿蒙跨平台社区：https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 filterator 的鸿蒙化适配指南 - 掌握声明式数据流过滤技术、助力鸿蒙应用构建极速且易维护的复杂列表筛选逻辑 前言 在 OpenHarmony 鸿蒙应用全场景信息交互的开发中，“数据清洗与过滤（Data Filtering）”是提升用户体验的关键环。当你需要在一个包含上万件商品的电商列表中，同时根据“价格区间”、“用户评分”、“物流时效”以及“是否有货”进行复合筛选时，嵌套的 if-else 或繁琐的迭代逻辑会让代码迅速变得臃肿且难以调试。filterator 作为一个专为 Dart 集合设计的声明式过滤利器，旨在通过链式调用与逻辑组合，将复杂的数据筛选过程转化为语义清晰、模块化的流式配置。本文将介绍如何在鸿蒙端利用 filterator 打造极致的数据交互体验。 一、原原理分析 / 概念介绍 1.1 基础原理 filterator 的核心逻辑是 基于谓词逻辑的集合管道过滤器

By Ne0inhk
Flutter 三方库 vendure 的适配鸿蒙实战 - 驾驭核心电商交易总网，实现 OpenHarmony 下的大并发 GraphQL 无头电商网关与数据强防腐

Flutter 三方库 vendure 的适配鸿蒙实战 - 驾驭核心电商交易总网，实现 OpenHarmony 下的大并发 GraphQL 无头电商网关与数据强防腐

欢迎加入开源鸿蒙跨平台社区：https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 vendure 的适配鸿蒙实战 - 驾驭核心电商交易总网，实现 OpenHarmony 下的大并发 GraphQL 无头电商网关与数据强防腐 前言 随着鸿蒙（OpenHarmony）生态的全球化出海，超级应用与万物互联的电商新纪年已经拉开帷幕。我们在将手机、平板、车载大屏甚至穿戴设备接入商城入口时，必须面对传统 RESTful 接口带来的巨大挑战：接口散乱、冗余数据多、联调效率低。 在处理类似 0308 批次这种千万级大字段的商品详情系统时，如果前端对后端接口的变动缺乏抗崩御能力，一次小小的结构调整就可能导致全链条的业务断裂，直接造成现金流的损失。我们需要一种“逻辑高层编排、数据按需即取、边界强悍防御”的接口总网。vendure 库正是为此而生的 GraphQL 客户端架构重炮。本文将详细揭秘它如何帮助你在鸿蒙端打造一套坚不可摧的交易底盘。 一、原理解析 / 概念介绍 1.

By Ne0inhk