在日常数据库开发中，“schema”一词经常出现，但它的含义在不同数据库系统中并不一致。在一些项目中，schema 常被工程师用来指代“表结构”的变更，而在某些数据库（例如 PostgreSQL）中，schema 又具有严格的命名空间含义。为了便于理解，这篇文章从概念、不同数据库的实现差异和典型应用场景三个角度进行整理。
一、Schema 在 SQL 标准中的定义
在 SQL 标准体系中，Schema 是数据库中的一个命名空间，用来组织和管理数据库对象，包括表、视图、索引、函数、存储过程等。其本质作用类似于操作系统中的目录，用于划分管理范围并避免命名冲突。
标准层级结构如下：
Server → Database → Schema → Table/View/Function/Index
也就是说，在标准定义中，schema 只是一个逻辑分组容器，而不是表结构本身。
二、不同数据库对 Schema 的实现差异
虽然 SQL 标准有明确定义，但实际数据库系统的实现存在差异，尤其是 MySQL 与 PostgreSQL。
PostgreSQL、Oracle、SQL Server：严格遵循 Schema 概念
这些数据库都支持一个 database 下存在多个 schema，每个 schema 都是独立的命名空间。例如在 PostgreSQL 中，可以在不同 schema 下创建同名表：
CREATE SCHEMA a;
CREATE SCHEMA b;
CREATE TABLE a.users (...);
CREATE TABLE b.users (...);
两张 users 表互不影响。
常见企业级数据库如 PostgreSQL、Oracle、SQL Server、DB2、Snowflake、Redshift 等，都支持 schema 的完整命名空间语义。
MySQL：Schema 等同于 Database
MySQL 并没有实现 SQL 标准中的 schema 层。MySQL 中的 schema 和 database 完全等价：
CREATE SCHEMA mydb;
CREATE DATABASE mydb;
这两条语句在 MySQL 中没有区别。因此，MySQL 不存在 database → schema 的两层结构，也无法在同一个 database 下创建同名表。
MySQL 中唯一的命名空间隔离粒度是 database。
SQLite、MongoDB 等：无 schema 或弱化 schema 概念
SQLite 只有一个数据库文件，不支持 schema 层级。MongoDB、Redis 等非关系型数据库也不具有 SQL 标准意义的 schema。
三、工程语境中的“schema 变更”通常指什么
在技术讨论中，人们常说“做一次 schema 变更”或“执行 schema migration”，但这里的 schema 已经偏离了 SQL 标准定义。
在工程实践中：
- schema change 通常指表结构的变更（DDL）
- schema migration 工具（如 Flyway、Liquibase、Rails migration）实际上管理的是表结构版本
- 这一用法与 schema 的“命名空间”含义无关
也就是说，在工程上下文中，schema 更接近“数据库结构设计整体”的含义，而不是 SQL 标准中的命名空间。
四、Schema 存在的意义
对于支持 schema 概念的数据库，schema 除了作为命名空间，还有以下常见用途：
- 多租户系统：不同租户使用不同 schema，各自隔离
- 系统模块划分：如 auth、analytics、core 等 schema 分别管理不同模块
- 避免命名冲突：不同 schema 下可存在同名表
- 数据版本管理：shadow schema、临时 schema 用于上线前的数据验证
这些能力在 MySQL 中无法通过数据库内层级直接实现，一般只能依赖多个 database 或其他机制。
五、总结
- Schema 在 SQL 标准中是 database 下的一层命名空间，用于组织数据库对象。
- PostgreSQL、Oracle、SQL Server 等数据库完整支持 schema，可以在不同 schema 下创建同名对象。
- MySQL 中没有独立的 schema 概念，schema 与 database 等价。
- 工程语境中的 “schema 变更” 通常指表结构变更，与 SQL 标准中的 schema 并无直接关系。