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可能卡住整个线程。 必须确保远端表有明确主键和高效索引，否则
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（按预估分片数放大），再本地归并。具体放多大，得看分片数量和排序离散度，没有固定公式，必须压测验证。
