分表后不支持跨表join和跨表索引覆盖，优化核心是为每张子表独立设计覆盖索引。垂直分表可正常join，水平分表需应用层或中间件路由查询并聚合结果，且每个子表须建包含where、order by及select字段的联合索引。
分表后跨表查询本身不支持原生 JOIN，更不存在“跨表索引覆盖”——因为索引只存在于单表（或单分区）内。所谓“优化”，本质是绕过跨表限制，把逻辑拆解、下推到各子表执行，再聚合结果。核心思路不是让一个索引覆盖多张表，而是让每张子表上的查询尽可能走覆盖索引。
分表类型决定查询方式
先明确你用的是哪种分表：
- 垂直分表：字段拆到不同表（如 users_base 和 users_ext），主键一致。这类可正常 JOIN，索引覆盖按单表设计即可，比如查 name+phone 就在 users_base 上建 (id, name, phone) 索引。
- 水平分表：数据按规则（如 user_id % 4）拆成 users_0、users_1 等。MySQL 不知道它们是同一逻辑表，无法自动关联。此时“跨表查询”需应用层或中间件（如 ShardingSphere、MyCat）路由并合并，每张物理表仍要独立设计覆盖索引。
覆盖索引必须落在每个子表上
不能指望一个索引跨 users_0 和 users_1 生效。优化重点是：
- 对每个子表，按实际高频查询字段建联合索引，且包含 WHERE 条件列 + SELECT 字段。例如常查
SELECT id, nickname, city FROM users_x WHERE status = 1 ORDER BY create_time DESC LIMIT 20，就在每个子表建(status, create_time, id, nickname, city)—— 注意顺序：过滤字段在前，排序字段次之，返回字段在后。 - 避免在子表上用
SELECT *，否则必然回表；即使分表了，回表仍是单表内的 I/O 开销。 - 若中间件支持“广播查询”（如查所有 users_x 中 status=1 的记录），更要确保每个子表的该查询能走覆盖索引，否则 N 张表各扫一遍，性能雪崩。
跨表聚合类查询的替代方案
像 SELECT COUNT(*) FROM users WHERE city = '北京' 这类跨子表统计，直接下发会变成 N 次查询再 SUM。优化方向有：
- 在应用层或中间件做结果合并，前提是每个子表查询都命中覆盖索引（如子表上有
(city)或(city, id)索引，COUNT(*) 可仅扫描索引）。 - 引入汇总表：每天定时将各子表的 city 统计写入 summary_city 表，查时直读汇总表。
- 用 ES 或 OLAP 引擎（如 Doris、StarRocks）承接分析类跨表查询，MySQL 只负责点查。
别踩这些坑
- 在子表上建了索引，但没在所有子表上统一创建 —— 少一张表就会降级为全表扫描。
- 误以为分表后“自动”支持全局唯一索引 —— 实际上每个子表的索引都是局部的，user_id 在 users_0 和 users_1 中可能重复。
- 用中间件时未开启 SQL 下推优化，导致本可在子表走索引的查询，被中间件拉全量数据后再内存过滤。
