MySQL实例是正在运行的mysqld服务进程，以及其对应的内存结构、线程池和相关资源集合，主要负责SQL解析、事务处理与文件读写操作；数据库则是实例内部的逻辑容器，一个实例可以统一管理多个数据库，但单个数据库不能脱离所属实例独立存在，更无法跨实例共享。
MySQL 实例是进程，不是“数据库”本身
你实际连接的并不是某一个数据库，而是 mysqld 这个持续运行中的服务进程。它会在内存中维护缓冲池、日志和线程，负责SQL语句解析、事务执行以及数据文件管理——几乎所有数据库操作都需要通过它完成。没有这个进程，磁盘上的 .ibd 文件本质上只是一组无法直接读写的二进制文件。
很多人容易混淆这两个概念：“我重启了数据库”，本质上通常是执行了 systemctl restart mysqld；“我备份了数据库”，也要分场景理解：如果只是导出数据，一般使用 mysqldump；如果要迁移整个MySQL实例，则通常需要复制 datadir、配置文件以及相关日志。
一台服务器上可以部署多个 MySQL 实例（例如使用不同端口、不同 datadir），这些实例之间不会共享内存，也不会共用磁盘路径。即使服务名都叫 mysql，它们依然是彼此独立的进程。
数据库是命名空间和权限边界，不是文件夹
很多人会把数据库理解成磁盘上的一个目录，但实际上，CREATE DATABASE app_db 并不只是创建一个空文件夹，而是在 MySQL 数据字典中登记一个逻辑容器。这个容器非常关键，它定义了默认字符集和校对规则，同时也是权限控制的重要边界。比如，可以为用户授予 SELECT ON app_db.* 权限，但这并不意味着用户能够自动跨库访问其他数据库对象。
表名只要求在当前数据库内唯一：app_db.users 和 hr_db.users 是两张完全不同、互不关联的表；而执行 DROP DATABASE app_db 时，会直接递归删除 datadir/app_db/ 下的所有相关文件，风险很高，通常难以恢复。
常见易错点：
- 忘记执行
USE app_db就直接运行CREATE TABLE，结果表没有建在预期库中，或者直接报错ERROR 1046 (3D000): No database selected - 误以为修改数据库字符集后，所有已有表都会自动统一编码——实际上，它通常只影响之后新建表的默认设置，现有表和字段仍保留原有编码
表才是存数据的地方，结构决定行为
真正承载业务数据的是表。字段类型、主键、索引、外键约束等规则，全部由表结构定义。数据库本身并不直接存储业务数据，也不会决定字段是否允许 NULL、是否自增，这些行为都明确写在 CREATE TABLE 语句中。
表最终如何落到磁盘上，与存储引擎密切相关：
- InnoDB（MySQL 8.0 默认引擎）：通常一张表对应一个
.ibd文件，包含数据和索引；如果该文件被删除，数据通常会彻底丢失 - MyISAM（已逐步淘汰）：通常拆分为
.MYD（数据）、.MYI（索引）、.sdi（结构定义）三个文件
外键约束要真正生效，还必须满足明确条件：REFERENCES 关联的两张表都必须使用 InnoDB 存储引擎，关联字段的数据类型必须严格一致（例如 INT 不能直接关联 BIGINT），并且被引用列需要有索引，通常是主键或唯一索引。
建表必须绑定数据库上下文
创建表时，必须明确它属于哪个数据库，常见且合法的写法有两种：
- 先切换数据库：
USE app_db;，再执行CREATE TABLE users (...) - 直接显式指定库名：
CREATE TABLE app_db.users (...)
在实际开发中，不建议省略库名后直接建表，尤其是在脚本执行、批量部署或自动化运维场景下——一旦连接时没有指定默认库，或者 USE 执行失败，表就可能建到错误的位置，这类线上问题非常常见。
跨库查询同样是 MySQL 使用中的高频难点：你不能只写 SELECT * FROM users JOIN orders 就期待系统自动把两个数据库中的表关联起来，而必须显式写成 SELECT * FROM app_db.users JOIN finance_db.orders 这样的完整形式，否则 MySQL 默认只会在当前数据库上下文中查找表。
