大表查询慢的核心是数据规模与访问模式不匹配，需协同设计分区与索引：分区键应选高选择性、高频过滤且分布均匀的字段（如tenant_id），避免单用递增ID或时间戳；索引须包含分区键并覆盖查询谓词，优先本地索引且首列为分区键；务必通过执行计划验证分区裁剪是否生效，并联动冷热分离与归档实现生命周期管理。

大表查询慢，核心问题往往不是SQL写得不好，而是数据规模与访问模式不匹配。分区解决数据物理分布问题，索引解决数据逻辑定位问题——二者必须协同设计，单用其一效果有限。

分区策略要匹配查询条件

分区不是越多越好，关键看WHERE里最常出现的过滤字段。比如订单表按order_time范围分区，但90%查询都带user_id，那按时间分区就难以跳过大量分区，实际扫描量仍很大。

• 优先选择高选择性、高频过滤、且值分布均匀的字段做分区键（如tenant_id、region_code）
• 避免用递增ID或时间戳单独分区，除非查询天然按该维度切片（如“查昨天所有日志”）
• 复合分区（如LIST-RANGE）适合多维筛选场景：先按业务线LIST分桶，再在每个桶内按时间RANGE子分区

索引必须覆盖分区键+查询谓词

普通索引在分区表上可能失效——如果索引不含分区键，优化器无法判断某条索引记录属于哪个分区，就不得不扫描全部分区的索引段。

• 全局索引慎用：跨分区维护成本高，DML性能下降明显；仅适用于极少数需按非分区字段高频点查的场景
• 推荐本地索引（LOCAL INDEX），且首列必须是分区键（如(tenant_id, status, create_time)），确保索引项与分区一一绑定
• WHERE中同时出现tenant_id = ? AND status = ?，索引就应把这两个字段前置，避免回表

执行计划必须验证分区裁剪是否生效

加了分区和索引不等于自动生效。务必用EXPLAIN PARTITIONS（MySQL）或DBMS_XPLAN（Oracle）看实际访问了哪些分区。

• 若显示partitions: all或大量分区被列出，说明分区键未参与过滤，或用了函数/表达式导致无法裁剪（如WHERE DATE(create_time) = '2024-01-01'）
• 索引字段存在隐式类型转换（如字符串字段用数字查询）会令本地索引失效，同样影响分区裁剪
• JOIN时注意驱动表分区键是否能传递到被驱动表：外连接或复杂子查询易导致裁剪失败

冷热分离与归档要联动分区管理

分区不只是提速工具，更是数据生命周期管理的载体。把历史分区设为只读、迁移至低成本存储，比DELETE或MOVE更高效安全。

• 每月新增一个RANGE分区，同时DROP或TRUNCATE三年前的分区（注意外键约束）
• 对访问极少的旧分区，可用ALTER TABLE ... EXCHANGE PARTITION导出为独立表，再压缩归档
• 只读分区可关闭其索引统计信息自动收集，减少维护开销