MySQL单实例不支持原生分布式查询；所谓分布式查询实为应用层或中间件（如ShardingSphere、MyCat）实现，FEDERATED引擎性能差且已废弃；可行方案是读写分离+应用路由，拆JOIN为多次单库查询并在内存关联。
MySQL 本身不支持原生分布式查询
直接说结论：MySQL 单实例无法跨多个物理节点自动执行 JOIN 或 UNION 类分布式查询。所谓“MySQL 分布式查询”，实际是应用层或中间件拼出来的——比如 ShardingSphere、MyCat、Vitess，或者业务代码手动查多个库再合并结果。
如果你在 EXPLAIN 里看到 SELECT_TYPE: UNION RESULT 或报错 ERROR 1210 (HY000): Incorrect arguments to UNION 却以为这是分布式能力，那第一步就得先厘清：你用的到底是不是真正的分库分表方案？
用 FEDERATED 引擎做跨库查询？别轻易上
FEDERATED 表看似能“远程查”，但实际性能极差，且 MySQL 8.0 默认禁用、5.7 已废弃警告。它本质是每次查询都建立新连接、拉全量数据到本地再处理，网络延迟 + 无索引下推 + 无并发控制，SELECT COUNT(*) FROM federated_table 可能卡住整个线程。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 必须确保远端表有明确主键和高效索引，否则
WHERE条件根本不下推 -
ORDER BY和LIMIT在远端不生效，所有数据先传回本地再排序 - 事务隔离弱，远端崩溃会导致本地查询失败，且无法参与 XA
真正可行的优化路径只有三条
不是调参数，而是选架构：
-
读写分离 + 应用路由：把
JOIN拆成多次单库查询，用IN列表批量获取关联 ID（注意max_allowed_packet限制），在内存里HashMap关联——适合关联字段稳定、ID 数量可控（ -
引入分片中间件：如
ShardingSphere-JDBC，配置好sharding-key后，它能把SELECT * FROM t_order o JOIN t_user u ON o.user_id = u.id自动改写为带分片条件的子查询并合并结果；但要求JOIN字段必须是分片键，否则退化为广播查询 -
冗余字段 + 异步 ETL：在订单表里加
user_name字段，通过binlog监听用户表变更同步更新——牺牲强一致性，换掉分布式JOIN
最容易被忽略的坑：跨分片 ORDER BY ... LIMIT
比如要查“每个城市销量 Top3 的商品”，如果城市分布在不同分片，中间件会向所有分片发 ORDER BY sales DESC LIMIT 3，然后本地再取全局 Top3——这看似合理，但实际漏掉了“某一分片第 4 名可能比其他分片第 1 名还高”的情况。
正确做法是让每个分片返回 LIMIT 10（按预估分片数放大），再本地归并。具体放多大，得看分片数量和排序离散度，没有固定公式，必须压测验证。
