数据库是MySQL中独立的命名空间和权限边界，表必须依附于数据库存在；删库会清空所有表，建表需显式指定库名或先USE；schema在MySQL中等同于database。
数据库是逻辑容器，表是数据载体
数据库不是“一堆表的打包文件”，而是MySQL服务中一个独立的命名空间和权限边界。你执行 CREATE DATABASE shop_db;，实际是在磁盘上初始化了一组系统文件（如 db.opt、表定义文件等），并注册进数据字典；而表必须依附于某个数据库存在——没有数据库，CREATE TABLE 会直接报错 ERROR 1046 (3D000): No database selected。
- 数据库可被不同用户分配不同权限（比如只允许开发人员读写
dev_shop_db，但禁止访问prod_shop_db） - 表名在同一个数据库内必须唯一，但在不同数据库中可以重名（
shop_db.users和hr_db.users完全无关） - 删除数据库（
DROP DATABASE）会**连带清空所有表及其中数据**，不可逆；删表（DROP TABLE）只影响单个结构
建表前必须 USE 或显式指定库名
很多初学者卡在「明明建了表，SELECT 却提示表不存在」，根本原因是没切换上下文。MySQL 不支持跨库隐式操作，SELECT * FROM users; 默认查当前数据库，不是全局搜索。
- 正确做法一（推荐）：
CREATE DATABASE myapp; USE myapp; CREATE TABLE users (id INT PRIMARY KEY, name VARCHAR(50));
- 正确做法二（不切库）：
CREATE TABLE myapp.users (id INT PRIMARY KEY, name VARCHAR(50));
—— 直接用数据库名.表名显式限定 - 错误典型：
CREATE DATABASE myapp; CREATE TABLE users (...);→ 此时未指定库，MySQL 会尝试在默认库（通常是information_schema或空上下文）建表，大概率失败或建到错地方
表结构决定数据行为，数据库只管隔离与权限
数据库本身不定义字段类型、主键、索引或外键；这些全是表级约束。也就是说，ALTER DATABASE 只能改字符集或排序规则（如 ALTER DATABASE myapp CHARACTER SET utf8mb4;），而加索引、设外键、调字段长度，都得对具体表操作。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 外键关联只在表之间生效，且要求：两张表引擎必须都是
InnoDB；关联字段类型严格一致（INT不能对BIGINT）；被引用列必须有索引（通常是主键或 UNIQUE） - 一张表可以有多个索引，但一个数据库的字符集设置会影响新表的默认字符集——若建表时没显式声明
CHARACTER SET，就会继承数据库设定 -
TRUNCATE TABLE比DELETE FROM快得多，但它本质是「删表重建」，会重置自增主键计数器；而数据库层面没有类似操作
别把 schema 和 database 当两回事（MySQL 特殊性）
在 PostgreSQL 或 Oracle 中，schema 是数据库内的子命名空间（类似文件夹），同一数据库下可有 public.users 和 audit.logs；但在 MySQL 中，schema 就是 database 的同义词——CREATE SCHEMA 和 CREATE DATABASE 完全等效，INFORMATION_SCHEMA 里的 SCHEMATA 表也只存数据库列表。
- 这意味着：MySQL 没有「库中套库」的能力；想逻辑隔离，只能靠多建库（
dev_xxx/test_xxx/prod_xxx） - 迁移或备份脚本里看到
CREATE SCHEMA IF NOT EXISTS，不用困惑，它就是建库命令 - 某些 ORM 或 GUI 工具显示 “Select Schema”，其实就是在让你选数据库
真正容易被忽略的是：数据库名本身参与 SQL 解析路径。比如触发器、存储过程、视图定义中若引用了表，MySQL 默认按当前数据库解析；一旦切换库，没加库名前缀的视图可能查不到数据——这不是 bug，是设计使然。
