大表查询慢的核心是数据规模与访问模式不匹配，需协同设计分区与索引：分区键应选高选择性、高频过滤且分布均匀的字段（如tenant_id），避免单用递增id或时间戳；索引须包含分区键并覆盖查询谓词，优先本地索引且首列为分区键；务必通过执行计划验证分区裁剪是否生效，并联动冷热分离与归档实现生命周期管理。
大表查询慢，核心问题往往不是SQL写得不好，而是数据规模与访问模式不匹配。分区解决数据物理分布问题，索引解决数据逻辑定位问题——二者必须协同设计，单用其一效果有限。
分区策略要匹配查询条件
分区不是越多越好，关键看WHERE里最常出现的过滤字段。比如订单表按order_time范围分区，但90%查询都带user_id，那按时间分区就难以跳过大量分区，实际扫描量仍很大。
- 优先选择高选择性、高频过滤、且值分布均匀的字段做分区键（如tenant_id、region_code）
- 避免用递增ID或时间戳单独分区，除非查询天然按该维度切片（如“查昨天所有日志”）
- 复合分区（如LIST-RANGE）适合多维筛选场景：先按业务线LIST分桶，再在每个桶内按时间RANGE子分区
索引必须覆盖分区键+查询谓词
普通索引在分区表上可能失效——如果索引不含分区键，优化器无法判断某条索引记录属于哪个分区，就不得不扫描全部分区的索引段。
迅易年度企业管理系统开源完整版
下载
系统功能强大、操作便捷并具有高度延续开发的内容与知识管理系统，并可集合系统强大的新闻、产品、下载、人才、留言、搜索引擎优化、等功能模块，为企业部门提供一个简单、易用、开放、可扩展的企业信息门户平台或电子商务运行平台。开发人员为脆弱页面专门设计了防刷新系统，自动阻止恶意访问和攻击；安全检查应用于每一处代码中，每个提交到系统查询语句中的变量都经过过滤，可自动屏蔽恶意攻击代码，从而全面防止SQL注入攻击
- 全局索引慎用：跨分区维护成本高，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导出为独立表，再压缩归档
- 只读分区可关闭其索引统计信息自动收集，减少维护开销
