一、现状

海量数据库跨分区索引失效，时间倒序占用查询资源，业务场景需要页码偏移，游标分页物法满足应用场景

二、现状概述及核心问题说明

2.1 数据库业务现状

当前业务核心数据表采用数据库分区存储架构，承载海量常态化业务增量数据，数据日积月累存储量级大、读写访问频次高，核心业务查询均需支持前端常规页码偏移分页查询需求，支撑日常业务运营、数据查询、后台管理等全场景使用。现阶段数据表已配置基础业务索引，但未结合分区特性及分页查询场景做定向索引优化，随着数据量持续增长，数据库查询性能逐步劣化，业务访问响应延迟升高，亟需专项优化整改保障业务平稳运行。

2.2 现存核心痛点问题

跨分区索引批量失效：核心业务查询未携带精准分区过滤条件，查询执行时无法触发数据库分区裁剪机制，每次分页查询需全量扫描多个数据分区，原有普通业务索引无法被数据库优化器正常命中，索引完全失效，查询执行效率极低，数据库CPU、IO资源持续高负载占用。

页码偏移场景无法使用游标索引优化：前端业务固定依赖传统页码偏移分页模式（Limit 大偏移量分页），业务场景及前端交互逻辑不支持改造为游标流式分页、主键增量分页等优化方案，常规深度分页优化手段无法落地，大页码分页查询全表扫描现象频发。

冷热数据混合存储拖累整体性能：数据表未做冷热数据分离归档，多年全量历史过期冷数据与近期高频访问热数据混合存储在同一张业务主表中，数据表体量持续臃肿，即便优化查询语句及索引，基础数据扫描基数过大，性能优化效果无法达标，长期运维及查询压力持续递增。

原表结构改造风险高：核心业务表关联上下游多个业务系统、接口及代码逻辑，直接修改表字段、分区规则、核心架构结构，极易引发业务报错、数据同步异常、接口中断等生产风险，需遵循最小改动原则开展优化工作。

三、整体优化实施总体思路及设计原则

3.1 核心优化总体思路

本次优化全程保留业务原表核心结构，不改动原有业务字段、主键、分区基础配置及上下游业务代码核心逻辑，以分区裁剪生效、索引精准命中、冷热数据分离、分页场景兼容为核心目标。通过新增默认时间查询过滤条件、新建时间首位复合专项索引、配置热数据保留周期、超期冷数据自动迁移归档至历史数据表四大核心举措，彻底解决跨分区索引失效、深度页码偏移分页性能卡顿问题，实现热数据查询毫秒级响应，冷数据归档隔离，数据库长期平稳运维。

3.2 优化设计核心原则

业务最小侵入原则：不修改原表结构、不调整原有分页查询语法、不改动前端页码交互逻辑，仅新增查询默认参数及索引，业务无感知上线。

索引适配分区原则：时间字段作为分区键，设置为复合索引第一列，优先触发分区裁剪，保障索引永久有效，杜绝跨分区全表扫描。

冷热分离分级查询原则：热数据留存业务主表支撑高频分页查询，冷数据归档历史表支撑低频溯源查询，分级管控、互不干扰。

运维自动化可控原则：数据归档、过期数据清理配置定时自动任务，支持手动启停、数据校验、一键回滚，运维操作简单可控。

四、详细优化实施方案

4.1 业务查询新增默认时间查询条件改造

针对所有涉及该核心业务表的分页查询接口、后台数据查询脚本、后台管理页面查询逻辑，统一新增默认时间范围查询过滤条件，作为必带查询参数，实现查询自动分区裁剪。前端页面未手动选择时间范围时，后端代码自动填充默认近N个月热数据时间范围；前端手动选择自定义时间范围时，按传入时间精准过滤查询，不强制限制。

热数据默认留存周期配置：根据业务查询高频场景，配置业务主表仅保留近3个月常态化热数据，可根据后续业务实际需求微调为1个月或6个月。所有分页查询SQL强制携带创建时间过滤条件，摒弃无时间过滤的全量查询逻辑。

优化前后SQL示例对比：优化前无时间过滤跨分区全量扫描SQL，优化后携带时间过滤、精准锁定单分区/少量分区查询SQL，从根源减少数据扫描范围，保障索引可命中。

4.2 新建时间复合专项索引配置

结合数据表分区规则及业务常用查询过滤字段，创建以时间字段为索引第一列的复合索引，适配分区裁剪及分页查询匹配逻辑，彻底解决索引失效问题。严禁将业务其他字段作为索引首列，确保数据库优先通过时间字段过滤分区，再匹配业务查询条件。

索引创建规范：索引结构优先采用「分区时间字段+高频查询条件字段+业务状态字段」组合，贴合日常分页查询高频过滤维度，索引创建过程选择业务低峰期执行，避免锁表影响生产业务读写。索引创建完成后，验证数据库执行计划，确认查询已走新建复合索引，无全表扫描、全分区扫描情况。

4.3 冷热数据分离归档表结构规划

新增业务历史归档数据表，归档表与原业务主表结构完全一致，包含所有字段、字段类型、字符集、排序规则、主键配置，不做任何结构修改，确保数据迁移无缝适配、查询逻辑统一。归档表仅用于存储超期冷数据，不配置高频查询索引，仅保留基础主键索引，适配低频历史数据溯源查询即可。

表命名规范：原业务主表名称保持不变，历史归档表命名规则为「原表名_history」，便于运维识别及脚本统一管理。日常核心业务分页查询仅访问原业务主表，历史数据溯源、数据对账等低频场景按需访问归档历史表。

4.4 超期数据定时归档及清理配置

配置定时归档运维任务，每日业务凌晨低峰期自动执行，核心执行逻辑分为两步：第一步将业务主表中超过N个月留存周期的冷数据批量迁移插入至对应历史归档表；第二步校验迁移数据条数一致性后，删除业务主表中已迁移的超期数据，保障主表仅留存热数据，体量持续可控。

归档任务配套数据校验机制：每次归档完成后自动比对主表删除数据量与归档表新增数据量，数据一致则任务正常结束，数据不一致则自动触发告警，停止删除操作，避免数据丢失。支持手动触发归档任务、归档数据回滚操作，适配特殊运维场景。

五、冷数据查询

5.1 全流程步骤明细

1.用户前端选择查询维度并提交任务：用户进入冷数据查询专属页面，自主勾选、填写所需查询维度，冷数据时间区间、业务类型、单据状态、所属机构、等自定义筛选条件，确认无误后点击提交查询报表任务。前端仅接收提交请求，不等待数据库查询结果，立即返回提交成功提示，用户可关闭页面或进行其他业务操作。

2.后台生成异步查询任务并进入任务队列：后端接收用户提交的查询维度参数，校验参数合法性及时间范围合规性，校验通过后生成唯一异步任务ID，记录任务发起人、查询条件、提交时间、任务状态为排队中，推入后台异步任务调度队列，不阻塞主线程业务逻辑。

3.异步线程独立执行冷数据归档表查询：后台异步任务调度中心按照配置并发阈值，依次调度排队任务，独立线程单独连接冷数据归档表执行多维度条件查询、数据汇总、统计计算，全程仅操作历史归档冷数据表，不触碰热数据主表，避免影响核心业务性能。

4.数据格式化完成后，后台自动按照预设报表模板生成Excel标准离线报表文件，文件命名包含任务ID、查询时间范围、生成日期、业务类型，报表文件自动存储至服务器指定文件目录或对象存储中，永久留存备份。

5.报表生成完成后，后台自动更新异步任务状态为执行成功，记录报表文件存储路径、文件大小、生成耗时；通过系统站内信、短信、企业微信等方式通知用户，提示冷数据查询报表已生成完毕，可进入任务列表下载查看。

六、备选方案

6.1当前痛点

数据表虽已配置常规业务复合索引，但一旦涉及跨分区查询，数据库优化器无法走索引检索，跨分区自动裁剪失效，索引完全失效；页码偏移分页无法使用游标优化最终整体查询慢，业务体验差

6.2实现方案

用户前端传入自定义查询时间起止范围，Java后台接收参数后，不直接将大跨度时间交给数据库执行，而是按照按月维度自动切割拆分，将一个跨月大时间范围，拆解为多个「单月起始时间-单月结束时间」独立查询条件。例如用户查询时间为2026-01-01至2026-03-31，程序自动拆分为2026年1月、2026年2月、2026年3月三个独立单月查询区间，每个查询条件严格只覆盖一个月度分区，确保每条SQL查询仅命中一个数据库物理分区。

6.3业务逻辑

前端正常传参 → Java后台解析时间范围 → 按月份自动拆分为多个单月独立查询条件 → 循环单分区精准查询数据库（次次走索引） → 内存合并所有分区数据 → 内存统一排序+分页切割 → 组装标准分页结构返回前端。全程数据库只做单分区简单索引查询，复杂跨分区逻辑、分页计算、数据合并全部放在应用层内存处理。