逻辑表是SQL中使用的虚拟表名，由中间件映射到真实物理表；物理表是MySQL实例中真实存在的表，如order_0、order_1，具备实际.ibd文件和索引。
不理解逻辑表与物理表，分库分表配置就容易配错路由规则，导致 INSERT 写到错库、SELECT 查不到数据，甚至事务跨物理库失败——这不是 bug，是概念混淆的必然结果。
逻辑表名是你写 SQL 时用的表名
你在应用里写的 SELECT * FROM order，这个 order 就是逻辑表名。它不对应磁盘上某个真实存在的 .ibd 文件，而是一个中间件（如 ShardingSphere、MyCat）或自研路由层维护的“别名”。中间件靠它决定该把这条 SQL 转发到哪个物理库、哪张物理表。
常见错误现象：
- 配置了分片规则但查询始终只走一个库 → 逻辑表名拼错（比如写了
orders但规则配的是order） - 新增分表后老 SQL 报
Table doesn't exist→ 应用仍用旧逻辑表名，而中间件未做兼容映射
物理表才是 MySQL 真正存储数据的地方
物理表是真实存在于某台 MySQL 实例上的表，比如 order_0、order_1，或者分布在 shard01 和 shard02 两个实例里的 order。它们有真实的 CREATE TABLE 语句、独立的索引、各自的 .ibd 文件。
关键差异点：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 字段类型/长度必须完全一致，否则跨物理表
UNION或中间件聚合会出错 - 主键策略要统一：如果用
user_id % 4分表，所有物理表的user_id都不能为NULL，且不能被应用层覆盖生成 -
auto_increment在水平分表中基本不可用，得换成雪花算法或号段模式
中间件靠逻辑-物理映射完成路由和合并
ShardingSphere 的 sharding-tables 配置、MyCat 的 scheme.xml，本质都是在定义：逻辑表 order → 物理库列表 + 物理表模板（如 order_$->{0..3}）+ 分片算法（如 user_id % 4）。
一旦映射关系没对齐，后果直接体现在 SQL 执行层：
-
WHERE user_id = 12345路由到order_1，但实际数据在order_3→ 查不到 -
GROUP BY status需从 8 张物理表聚合，但其中 2 张因库连接超时未返回 → 结果缺失 - 跨库
JOIN（如order JOIN user）未开启广播表或绑定表配置 → 中间件拒绝执行或性能爆炸
最容易被忽略的一点：逻辑表可以跨异构源（MySQL + ES + HBase），但物理表结构不一致时，中间件的 UNION 合并会静默丢列或报类型转换异常——这种问题往往压测才暴露，上线后查数不准却找不到根因。
