MySQL中schema与database完全等价，CREATE SCHEMA即CREATE DATABASE；分库应依据数据冷热、一致性要求和DDL频率，而非微服务数量，避免权限、备份、监控及事务恢复风险。
MySQL 8.0 中没有独立的 SCHEMA 概念——CREATE SCHEMA 就是 CREATE DATABASE 的同义词，二者完全等价。所谓“规划 Schema 与 Database 的逻辑边界”，本质是在设计阶段决定：哪些业务模块共用一个数据库（即一个命名空间），哪些必须物理隔离。
为什么不能按“微服务数量”一对一建库
常见误区是每个微服务配一个 DATABASE。这在 MySQL 8.0 下会快速暴露问题：
- 系统库
mysql中的权限表（如tables_priv）行数随库数量线性增长，超千库后GRANT操作明显变慢 - 备份工具（如
mysqldump --all-databases）默认串行导出所有库，库越多，单次全量备份窗口越难控制 - 监控粒度粗——Percona PMM、Zabbix 等默认只按库维度采集
InnoDB_buffer_pool_reads，无法下钻到“某张订单表”级别 -
information_schema查询本身变重：比如SELECT COUNT(*) FROM information_schema.tables WHERE table_schema = 'xxx'在 500+ 库环境下响应超 2s
按数据生命周期和访问模式分库更可靠
真正影响运维和性能的是数据冷热、一致性要求、DDL 频率，不是服务边界。例如：
Mysql Skill 1.0.0 (3)
下载
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
- 高频交易类表（
orders,payments）和低频报表类表（daily_sales_summary）不应放在同一库——前者需频繁ALTER TABLE加字段，后者可能锁表 10 分钟，波及所有表 - 用户中心（
users,profiles）和日志中心（audit_logs,click_events）必须分库：后者写入吞吐高、保留周期短、常被TRUNCATE，混在一起会导致ibdata1文件碎片化加剧 - 多租户场景下，若租户数据量差异极大（如 SaaS 中大客户单库 200GB，小客户平均 500MB），建议按量级分组建库，而非每个租户一个库
权限收敛与跨库查询的实际限制
MySQL 不支持跨 DATABASE 的 FOREIGN KEY，也不支持 ALTER TABLE ... RENAME TO other_db.table_name（除非同实例且有 SUPER 权限）。这意味着：
- 想用外键强制引用完整性？所有关联表必须在同一
DATABASE内 - 想把
billing库中一张表迁到finance库？只能CREATE TABLE finance.invoice LIKE billing.invoice+INSERT INTO ... SELECT，无法原子搬迁 -
GRANT SELECT ON billing.* TO 'reporter'@'%'和GRANT SELECT ON finance.* TO 'reporter'@'%'是两条独立语句，漏配一个库就查不到数据 - 应用层 JOIN 跨库表时，MySQL 无法下推谓词，
EXPLAIN显示type: ALL且无索引提示，性能风险极高
最易被忽略的一点：MySQL 8.0 的事务性数据字典让 DATABASE 成为真正的原子操作单元——DROP DATABASE 不再是简单删文件夹，而是走事务日志回滚段清理。一旦误删，恢复依赖备份+binlog，没有“反悔键”。所以分库决策不是技术选型，而是事故半径控制。
