federated表查不到数据主因是远程连接失败后静默降级为空表，需确保show engines中状态为yes、远程地址mysql进程可达、字符集一致、结构严格匹配且不支持事务。
跨库查询不是不能做，而是必须明确代价——它天然牺牲一致性、吞吐量和可维护性。直接在应用层拼 JOIN 或硬写多库 UNION ALL 是最常见也最危险的起点。
用 FEDERATED 引擎连表时为什么查不到数据？
FEDERATED 表本质是远程代理，不存真实数据，所有读写都转发到目标库。但默认 MySQL 5.7+ 已禁用该引擎，且存在多个隐性限制：
-
show engines;必须看到FEDERATED显示为YES，否则建表会静默失败或报错ERROR 1286 (42000): Unknown storage engine 'FEDERATED' - 远程库连接地址必须可被本地 MySQL 进程直连（注意：不是应用服务器能连，而是 MySQL server 进程自身网络可达）
- 字符集不一致会导致字段映射失败，建表后
DESCRIBE显示字段为空或类型错误 - 不支持事务，
INSERT/UPDATE/DELETE在本地执行成功，但远程失败时无回滚机制
示例中建表语句必须严格匹配远程表结构，包括字段顺序、长度、是否允许 NULL —— 少一个 DEFAULT NULL 都可能让查询返回空结果。
客户端聚合时 ORDER BY 和 LIMIT 怎么写才不出错？
分片后“取第 20–30 条”不能简单对每个分片执行 LIMIT 10 OFFSET 20，那样会漏数据。正确做法是每个分片取足够多的候选行（比如 LIMIT 100），再在应用内存中合并、排序、截断：
- 若排序字段是分片键（如
user_id），可先路由到单一分片，避免聚合 - 若排序字段是时间（如
create_time），需预估偏移量影响范围：假设共 5 个分片，要取第 20–30 条，则每个分片至少取LIMIT 30，否则可能某一分片实际只贡献 2 条，导致总数不足 - 分页深度越大，各分片需取的数据越多，网络和内存开销呈线性增长；超过第 100 页基本不可行
代码层面不要依赖数据库自动去重，UNION 或 DISTINCT 必须在客户端完成，因为各分片的主键可能重复（如自增 ID 未全局唯一）。
为什么 MyCat / ShardingSphere 的 SQL 支持总有盲区？
中间件解析 SQL 是有限状态机，不是完整编译器。以下操作极易触发“不支持该语法”错误：
-
GROUP BY字段未出现在SELECT列表中（MySQL 兼容模式开启前会报错） - 子查询里含跨分片表，例如
SELECT * FROM t_order WHERE user_id IN (SELECT user_id FROM t_user)，中间件无法推导t_user分片规则 -
ORDER BY同时含分片键和非分片键字段，如ORDER BY user_id, create_time，部分版本会降级为全分片扫描 - 使用函数如
DATE(create_time)作为分片键条件，中间件无法识别其等价于某个分片范围
关键点：中间件的“透明”是假象，它只对标准 CRUD + 简单 JOIN 透明；一旦涉及计算、嵌套或模糊条件，就必须查文档确认当前版本是否支持，不能靠测试猜。
真正该优先做的：从设计上消灭跨库查询
所有技术方案都在兜底，但最高性价比的解法是让跨库查询根本不需要发生：
- 把高频关联的表（如
order和order_item）用相同分片键（如user_id）落在同一库同一分片，JOIN自然收敛到单节点 - 将低频、强一致性要求不高的维度表（如
region、category）设为全局表，在每个分片库中冗余一份 - 把需要聚合统计的场景（如“最近 7 天订单总额”）异构到
Elasticsearch或ClickHouse，不在 OLTP 库上硬扛
最容易被忽略的是：分片键选错比不会用中间件后果更严重。一个按 order_id 分片的订单库，只要业务要查“某个用户的全部订单”，就注定要跨库；而换用 user_id，90% 的查询都能命中单分片。
