先说明一下这个标题我拿到的时候第一反应是又是个常规的“系统慢”优化但仔细一琢磨21亿这个量级加上月结这个特定场景背后涉及的问题完全不在一根弦上。财务月结本身就是企业ERP系统里压力最集中的时刻数据量到了这个级别常规的加索引、扩内存基本不解决根本问题。我把自己在几个大型制造业、零售业项目里的实操经验结合这个场景完整拆一遍希望能给正在被“月结卡死”的同行一点可落地的参考。1. 先把“困局”两个字拆透月结为什么是财务系统的生死时刻月结字面意思就是财务在每个月固定时点把账期关掉完成计提、摊销、成本结转、汇兑损益等一连串动作最终出三大报表。听起来就是个固定的批量流程但真正做过的人都知道这个流程是全公司所有业务模块数据汇流的终点。销售部门月底冲量单据量可以翻三倍采购部门集中月底收货库存事务处理表的写入量暴涨生产部门月底做完工汇报工单状态更新是平时的好几倍。所有的这些业务动作最终都会通过接口或标准表同步到财务模块变成总账凭证行。模块之间的耦合在这个时点集中爆发任何一张中间表的锁等待都可能引发多米诺骨牌效应。1.1 21亿是什么概念数据体量带来的质变21亿行数据是什么概念我给你几个直观的参照单表行数超过21亿意味着即使只做全表扫描的元数据读取也要消耗掉大量的I/O带宽。如果有一张核心凭证行表达到这个量级普通的B树索引即使命中率很高回表的成本也极其惊人。对于关系型数据库而言21亿行往往意味着表的物理存储达到数百GB甚至上TB级别这已经需要分区、压缩等高级特性介入。更关键的是月结不是只查一张表而是多张大表之间做关联、聚合、插入。数据量到这个级别SQL执行计划哪怕差一点点都可能从分钟级恶化到小时级。1.2 财务月结的核心业务逻辑不是单纯的技术加速可以覆盖很多人以为月结慢就是数据库性能问题其实业务逻辑本身的结构才是根源。财务月结的完整流程大致包括各业务模块关账限制本期间单据录入或标记关闭总账的日记账导入汇总子模块传入的凭证凭证过账将凭证行的数据按科目、期间汇总到余额表重估、折旧、成本分摊等周期性凭证生成外币重估与汇兑损益结转期间关闭锁死当前期间数据这中间每一步都可能产生临时表、中间表且每一步都对上一步的数据有强依赖。流程串行数据量大任何一个环节失败都需要回滚重来这就是困局的本质。2. 目标状态与整体设计思路从串行批量到并行可控面对21亿的体量月结方案不能只盯着数据库调优需要从业务编排到数据库底层做整体设计。我最后落地的整体思路可以概括为三步拆流程、改机制、并执行。2.1 “拆流程”的核心逻辑把大事务拆成小事务月结慢的第一个原因是单个事务处理的数据量过大。比如总账过账如果一次性处理全月几亿行凭证数据事务所持有的UNDO、锁、日志都会爆掉。所以第一步必须做的是把月结流程拆成若干个可以独立运行的小批次。怎么拆最推荐的是按业务模块拆应收模块的凭证先过账然后应付模块再然后存货模块。模块之间如果存在依赖比如成本计算必须在存货过账之后那就设置依赖顺序即可。这种拆分的另一个好处是如果某个模块的数据有问题止损范围可以控制在单个模块内不用整个月结推倒重来。2.2 “改机制”的关键路径抛弃报表型月结拥抱增量计算第二个痛点是很多人忽视的月结期间的大量操作其实是在做重复计算。传统的月结是从头扫描全月数据重新汇总21亿行全表聚合任何数据库都吃不消。我当时的做法是引入增量汇总机制日常每天跑批时把当天的凭证影响结果预计算写入汇总中间表月结时只处理期末期间的增量数据然后与中间表做合并这样月结时的数据扫描量从21亿行降为几百万行性能瓶颈自然消失这套机制还有个隐藏收益日清的校验效率大大提高。因为中间表本身就是一套按科目、期间、公司维度组织的预汇总数据核对余额差异时可以直接定位到具体某一天而不是去翻原始凭证流水的家底。2.3 “并执行”的改造原则无依赖的环节并行有依赖的环节增量串行流程是月结耗时的最大元凶。比如某集团有10个公司代码每个公司的月结数据体量都不小传统做法是一个公司一个公司顺序跑跑完A再跑B。但不同公司之间的月结业务上是完全独立的完全可以并行处理。在数据库层面我做了三件事来支撑并行改造所有月结相关表都改造为按公司代码或按期间分区确保并行任务之间尽量不访问相同的物理分区关键查询都加上了公司代码的过滤条件让执行计划可以走分区裁剪并行度根据服务器的CPU核心数做了压测验证避免盲目调高并行度导致资源争用反而更慢3. 核心细节拆解索引、分区、执行计划的几个关键坑这部分的每一项我都在生产环境里踩过坑。很多优化手段理论上没毛病实际一上生产就出幺蛾子原因往往就藏在这些细节里。3.1 索引不是越多越好21亿表的索引设计原则数据量越大索引的维护成本越高。每增加一个索引插入和更新时的额外写操作和索引分裂代价都呈指数级上升。在21亿的表上一个不常用的二级索引单独占用几十GB空间都不稀奇还会拖慢日常的DML操作。我的索引设计原则就三条为月结核心SQL定制联合索引而不是沿用OLTP时代留下的老索引删除或者禁用长期未被使用的冗余索引特别是那些低选择性的单列索引大量使用复合索引和覆盖索引避免回表具体来说凭证行表的典型查询模式是WHERE company_code ? AND period ? AND account_code ?这种场景建立(company_code, period, account_code)的联合索引就非常关键而一个单独的account_code索引在这种查询里几乎没有价值。3.2 分区策略的实战选择范围分区与列表分区的取舍21亿行数据不做分区纯粹是给自己找不痛快。分区带来的核心收益有两个分区裁剪和分区交换。分区裁剪是指SQL查询条件如果带上分区键数据库可以只扫描相关的几个分区而不是全表。我对凭证行表采用的是范围分区按月分区因为所有月结查询几乎都带期间条件。分区交换则是月结阶段的大招。比如清算完一个期间的数据将其加载到一张结构相同的临时表然后通过分区交换的方式把临时表的数据换入主表整个过程几乎秒级完成不会产生大量的日志和锁竞争。3.3 执行计划“漂移”的治理别以为对了就永远对执行计划变化是月结优化的隐形杀手。可能平时跑得飞快的SQL到了数据量暴涨的月底优化器选了一个完全错误的执行计划导致性能断崖式下跌。我当时采取的治理手段包括统计信息收集策略调整月度数据量波动大的表收集频率提高到按周而不是依靠默认的自动任务。SQL Plan ManagementSPM对核心月结SQL手动固定执行计划防止优化器在数据量陡增时“飘掉”。Hint的适度使用对于优化器明显判断错误的场景通过Hint强制指定正确的驱动表、关联顺序或并行度。4. 实操记录从“月结跑48小时”到“完成仅需5小时”的完整路径整个优化过程前后持续了大概两个多月分四个阶段推进每个阶段都有明确的量化目标。我把关键的实操过程完整记录下来可以直接作为一份参考方案来对照。4.1 第一阶段基础诊断——找出真正的瓶颈动刀之前先做了三天的全链路监控。重点看了三个指标月结期间数据库的等待事件分布尤其关注db file sequential read和enq: TX - row lock contention每个月结步骤涉及的SQL按执行时间倒序排列找出Top 10最耗时的SQL系统资源状态看CPU、内存、I/O是否有明显瓶颈诊断结果让我很意外最耗时的不是某个复杂的聚合查询而是大量重复的、低效的单条凭证插入操作。因为月结逻辑是一个循环一条凭证一条凭证地插入循环几百万次每次提交都消耗大量事务日志写I/O。4.2 第二阶段SQL性能优化——改写到极致针对诊断结果组建了一个小组专门重写月结相关SQL。几个核心动作把PL/SQL循环中的逐条INSERT替换为FORALL批量插入减少上下文切换次数对凭证生成逻辑做了集合化改造用一条复杂的SQL替代循环计算减少过程式逻辑对临时表的数据类型做了调整避免隐式转换导致索引失效这一阶段的效果非常明显整体月结耗时从48小时降到了22小时左右减少了超过一半。但这个成绩离目标还远真正的质变来自下一阶段的架构调整。4.3 第三阶段并行与分区改造——突破物理极限这个阶段做了几件关键的事按公司代码拆分月结任务每个公司代码独立跑一个流程实例由调度平台统一管理并行度核心大表做按月分区并按公司代码增加二级分区确保并行任务之间分区隔离将报表口径的数据查询切换到物化视图提前预计算好月结期间不需要实时关联原始大表其中代价最大的是分区改造涉及近10张核心大表的重建和数据迁移。我采用在线重定义的方式停机窗口仅用了4个小时就完成了TB级表结构变更。4.4 第四阶段基础设施与参数调优——把压死骆驼的最后一根稻草拿掉在数据库和基础设施层面我做了以下调整UNDO表空间扩容之前月结期间多次出现快照过旧错误就是因为大事务对UNDO空间的消耗严重超过预期日志缓冲区与日志文件优化把重做日志组加大减少日志切换频率并行度参数调整parallel_max_servers和parallel_degree_limit结合压测结果设定避免并行服务器进程被耗尽存储I/O负载均衡将日志文件和数据文件分散到不同的存储路径降低I/O争用到这一步月结总耗时降到了约5小时并且在验证了连续三个月的数据准确性后正式作为上线基线。5. 常见问题与排查方法月结性能问题速查表在实际优化和后续运维过程中我整理了一份高频问题速查表几乎覆盖了月结性能问题的大部分典型场景。症状表现可能原因快速排查方法解决措施月结某一步骤卡死不动锁等待另一个事务未提交查询锁等待视图定位阻塞源找到阻塞Session评估后Kill或等其提交报ORA-01555快照过旧UNDO空间不足或UNDO保留时间过短查看UNDO表空间使用率和undo_retention扩容UNDO调大undo_retention并行任务之间相互等待分区设计不合理存在热点分区查看实例活动会话分析等待事件调整分区策略分散热点某个SQL昨天快今天慢统计信息过期执行计划漂移对比执行计划检查表的统计信息手动收集统计信息SPM固定计划数据插入速度越来越慢索引碎片严重或者表空间碎片查看索引状态和表空间使用情况定期重组索引回收碎片空间临时表空间爆满大量排序或哈希关联操作查看临时表空间使用率扩容临时表空间优化SQL减少排序5.1 关于“锁等待”的一个独立坑月结最常见的卡死场景就是锁等待。但很多人排查时陷入一个误区看到enq: TX - row lock contention就去杀会话结果发现杀完另一个又卡住没完没了。正确做法是先找出锁的持有链谁锁了谁根因是谁。我见过一个典型案例月结卡死是因为一张业务单据审批流程没有关闭某个用户在前台界面上挂了一个未提交的事务导致后台月结任务被无限期阻塞。这种情况下杀后台任务是没用的找到根因会话并处理才是正解。5.2 关于“临时表空间”的一个补充21亿数据的月结涉及大量排序、去重、关联操作临时表空间使用量经常突破预期。我踩过的一个教训是不要只看临时表空间的当前使用率还要关注历史峰值否则月结峰值一上来就直接“临时表空间不足”报错整个流程崩溃。我的做法是提前做一轮压测把月结数据量放大到平时的1.5倍观察临时表空间的最大消耗量然后按这个峰值的1.5倍去配置临时表空间大小。6. 从21亿月结优化延展出的通用经验项目收尾后我把这套方法论沉淀下来后来在几个数据量没那么大的企业ERP系统迁移、月结提速项目里继续复用验证了这套思路的通用性。6.1 月结优化的核心永远是“业务理解”先行首先不去理解财务月结的业务逻辑就去调优大概率是瞎忙活。比如你辛苦优化了一条SQL结果发现这个SQL在月结流程里根本不在关键路径上那优化了也白优化。所以我在每个项目里的第一件事都是拉通财务月结的完整流程图找出每一步的数据来源、数据量级、依赖关系然后再谈技术手段。6.2 “增量化”思想适用于绝大多数大规模批处理不只是财务月结任何大规模批处理场景——存货核算、成本分摊、薪酬计算、报表汇总——都适用“平时代算、期末增量”的通用思想。本质都是避免在关键时点做大量重复计算。如果你现在面临的问题不是月结而是某个天天跑的批量任务越来越慢不妨也往这个方向想想是不是可以每天只处理增量数据而不是每天全量重算6.3 永远给月结留Plan B优化做得再好也架不住偶尔的业务数据异常、数据库抖动、甚至存储故障。月结是财务披露的生命线必须有Plan B。我最后在系统层面做了两层兜底月结检查点机制把月结流程拆成多个检查点每个检查点记录已完成状态流程中断后可以从最近检查点续跑不用全部重来备用窗口预留月结期间预留独立的维护窗口如果主流程出问题立刻切换到备用环境或备用时间窗口运行这两层兜底成本不高但在关键时刻能救命。有一次生产环境存储故障导致月结中断就是靠检查点恢复机制在2小时内完成了续跑没有影响财务出表时间。如果你正在为月结头疼建议先把检查点机制做上再谈性能优化。
21亿数据月结优化实战：从48小时到5小时的数据库调优全解析
先说明一下这个标题我拿到的时候第一反应是又是个常规的“系统慢”优化但仔细一琢磨21亿这个量级加上月结这个特定场景背后涉及的问题完全不在一根弦上。财务月结本身就是企业ERP系统里压力最集中的时刻数据量到了这个级别常规的加索引、扩内存基本不解决根本问题。我把自己在几个大型制造业、零售业项目里的实操经验结合这个场景完整拆一遍希望能给正在被“月结卡死”的同行一点可落地的参考。1. 先把“困局”两个字拆透月结为什么是财务系统的生死时刻月结字面意思就是财务在每个月固定时点把账期关掉完成计提、摊销、成本结转、汇兑损益等一连串动作最终出三大报表。听起来就是个固定的批量流程但真正做过的人都知道这个流程是全公司所有业务模块数据汇流的终点。销售部门月底冲量单据量可以翻三倍采购部门集中月底收货库存事务处理表的写入量暴涨生产部门月底做完工汇报工单状态更新是平时的好几倍。所有的这些业务动作最终都会通过接口或标准表同步到财务模块变成总账凭证行。模块之间的耦合在这个时点集中爆发任何一张中间表的锁等待都可能引发多米诺骨牌效应。1.1 21亿是什么概念数据体量带来的质变21亿行数据是什么概念我给你几个直观的参照单表行数超过21亿意味着即使只做全表扫描的元数据读取也要消耗掉大量的I/O带宽。如果有一张核心凭证行表达到这个量级普通的B树索引即使命中率很高回表的成本也极其惊人。对于关系型数据库而言21亿行往往意味着表的物理存储达到数百GB甚至上TB级别这已经需要分区、压缩等高级特性介入。更关键的是月结不是只查一张表而是多张大表之间做关联、聚合、插入。数据量到这个级别SQL执行计划哪怕差一点点都可能从分钟级恶化到小时级。1.2 财务月结的核心业务逻辑不是单纯的技术加速可以覆盖很多人以为月结慢就是数据库性能问题其实业务逻辑本身的结构才是根源。财务月结的完整流程大致包括各业务模块关账限制本期间单据录入或标记关闭总账的日记账导入汇总子模块传入的凭证凭证过账将凭证行的数据按科目、期间汇总到余额表重估、折旧、成本分摊等周期性凭证生成外币重估与汇兑损益结转期间关闭锁死当前期间数据这中间每一步都可能产生临时表、中间表且每一步都对上一步的数据有强依赖。流程串行数据量大任何一个环节失败都需要回滚重来这就是困局的本质。2. 目标状态与整体设计思路从串行批量到并行可控面对21亿的体量月结方案不能只盯着数据库调优需要从业务编排到数据库底层做整体设计。我最后落地的整体思路可以概括为三步拆流程、改机制、并执行。2.1 “拆流程”的核心逻辑把大事务拆成小事务月结慢的第一个原因是单个事务处理的数据量过大。比如总账过账如果一次性处理全月几亿行凭证数据事务所持有的UNDO、锁、日志都会爆掉。所以第一步必须做的是把月结流程拆成若干个可以独立运行的小批次。怎么拆最推荐的是按业务模块拆应收模块的凭证先过账然后应付模块再然后存货模块。模块之间如果存在依赖比如成本计算必须在存货过账之后那就设置依赖顺序即可。这种拆分的另一个好处是如果某个模块的数据有问题止损范围可以控制在单个模块内不用整个月结推倒重来。2.2 “改机制”的关键路径抛弃报表型月结拥抱增量计算第二个痛点是很多人忽视的月结期间的大量操作其实是在做重复计算。传统的月结是从头扫描全月数据重新汇总21亿行全表聚合任何数据库都吃不消。我当时的做法是引入增量汇总机制日常每天跑批时把当天的凭证影响结果预计算写入汇总中间表月结时只处理期末期间的增量数据然后与中间表做合并这样月结时的数据扫描量从21亿行降为几百万行性能瓶颈自然消失这套机制还有个隐藏收益日清的校验效率大大提高。因为中间表本身就是一套按科目、期间、公司维度组织的预汇总数据核对余额差异时可以直接定位到具体某一天而不是去翻原始凭证流水的家底。2.3 “并执行”的改造原则无依赖的环节并行有依赖的环节增量串行流程是月结耗时的最大元凶。比如某集团有10个公司代码每个公司的月结数据体量都不小传统做法是一个公司一个公司顺序跑跑完A再跑B。但不同公司之间的月结业务上是完全独立的完全可以并行处理。在数据库层面我做了三件事来支撑并行改造所有月结相关表都改造为按公司代码或按期间分区确保并行任务之间尽量不访问相同的物理分区关键查询都加上了公司代码的过滤条件让执行计划可以走分区裁剪并行度根据服务器的CPU核心数做了压测验证避免盲目调高并行度导致资源争用反而更慢3. 核心细节拆解索引、分区、执行计划的几个关键坑这部分的每一项我都在生产环境里踩过坑。很多优化手段理论上没毛病实际一上生产就出幺蛾子原因往往就藏在这些细节里。3.1 索引不是越多越好21亿表的索引设计原则数据量越大索引的维护成本越高。每增加一个索引插入和更新时的额外写操作和索引分裂代价都呈指数级上升。在21亿的表上一个不常用的二级索引单独占用几十GB空间都不稀奇还会拖慢日常的DML操作。我的索引设计原则就三条为月结核心SQL定制联合索引而不是沿用OLTP时代留下的老索引删除或者禁用长期未被使用的冗余索引特别是那些低选择性的单列索引大量使用复合索引和覆盖索引避免回表具体来说凭证行表的典型查询模式是WHERE company_code ? AND period ? AND account_code ?这种场景建立(company_code, period, account_code)的联合索引就非常关键而一个单独的account_code索引在这种查询里几乎没有价值。3.2 分区策略的实战选择范围分区与列表分区的取舍21亿行数据不做分区纯粹是给自己找不痛快。分区带来的核心收益有两个分区裁剪和分区交换。分区裁剪是指SQL查询条件如果带上分区键数据库可以只扫描相关的几个分区而不是全表。我对凭证行表采用的是范围分区按月分区因为所有月结查询几乎都带期间条件。分区交换则是月结阶段的大招。比如清算完一个期间的数据将其加载到一张结构相同的临时表然后通过分区交换的方式把临时表的数据换入主表整个过程几乎秒级完成不会产生大量的日志和锁竞争。3.3 执行计划“漂移”的治理别以为对了就永远对执行计划变化是月结优化的隐形杀手。可能平时跑得飞快的SQL到了数据量暴涨的月底优化器选了一个完全错误的执行计划导致性能断崖式下跌。我当时采取的治理手段包括统计信息收集策略调整月度数据量波动大的表收集频率提高到按周而不是依靠默认的自动任务。SQL Plan ManagementSPM对核心月结SQL手动固定执行计划防止优化器在数据量陡增时“飘掉”。Hint的适度使用对于优化器明显判断错误的场景通过Hint强制指定正确的驱动表、关联顺序或并行度。4. 实操记录从“月结跑48小时”到“完成仅需5小时”的完整路径整个优化过程前后持续了大概两个多月分四个阶段推进每个阶段都有明确的量化目标。我把关键的实操过程完整记录下来可以直接作为一份参考方案来对照。4.1 第一阶段基础诊断——找出真正的瓶颈动刀之前先做了三天的全链路监控。重点看了三个指标月结期间数据库的等待事件分布尤其关注db file sequential read和enq: TX - row lock contention每个月结步骤涉及的SQL按执行时间倒序排列找出Top 10最耗时的SQL系统资源状态看CPU、内存、I/O是否有明显瓶颈诊断结果让我很意外最耗时的不是某个复杂的聚合查询而是大量重复的、低效的单条凭证插入操作。因为月结逻辑是一个循环一条凭证一条凭证地插入循环几百万次每次提交都消耗大量事务日志写I/O。4.2 第二阶段SQL性能优化——改写到极致针对诊断结果组建了一个小组专门重写月结相关SQL。几个核心动作把PL/SQL循环中的逐条INSERT替换为FORALL批量插入减少上下文切换次数对凭证生成逻辑做了集合化改造用一条复杂的SQL替代循环计算减少过程式逻辑对临时表的数据类型做了调整避免隐式转换导致索引失效这一阶段的效果非常明显整体月结耗时从48小时降到了22小时左右减少了超过一半。但这个成绩离目标还远真正的质变来自下一阶段的架构调整。4.3 第三阶段并行与分区改造——突破物理极限这个阶段做了几件关键的事按公司代码拆分月结任务每个公司代码独立跑一个流程实例由调度平台统一管理并行度核心大表做按月分区并按公司代码增加二级分区确保并行任务之间分区隔离将报表口径的数据查询切换到物化视图提前预计算好月结期间不需要实时关联原始大表其中代价最大的是分区改造涉及近10张核心大表的重建和数据迁移。我采用在线重定义的方式停机窗口仅用了4个小时就完成了TB级表结构变更。4.4 第四阶段基础设施与参数调优——把压死骆驼的最后一根稻草拿掉在数据库和基础设施层面我做了以下调整UNDO表空间扩容之前月结期间多次出现快照过旧错误就是因为大事务对UNDO空间的消耗严重超过预期日志缓冲区与日志文件优化把重做日志组加大减少日志切换频率并行度参数调整parallel_max_servers和parallel_degree_limit结合压测结果设定避免并行服务器进程被耗尽存储I/O负载均衡将日志文件和数据文件分散到不同的存储路径降低I/O争用到这一步月结总耗时降到了约5小时并且在验证了连续三个月的数据准确性后正式作为上线基线。5. 常见问题与排查方法月结性能问题速查表在实际优化和后续运维过程中我整理了一份高频问题速查表几乎覆盖了月结性能问题的大部分典型场景。症状表现可能原因快速排查方法解决措施月结某一步骤卡死不动锁等待另一个事务未提交查询锁等待视图定位阻塞源找到阻塞Session评估后Kill或等其提交报ORA-01555快照过旧UNDO空间不足或UNDO保留时间过短查看UNDO表空间使用率和undo_retention扩容UNDO调大undo_retention并行任务之间相互等待分区设计不合理存在热点分区查看实例活动会话分析等待事件调整分区策略分散热点某个SQL昨天快今天慢统计信息过期执行计划漂移对比执行计划检查表的统计信息手动收集统计信息SPM固定计划数据插入速度越来越慢索引碎片严重或者表空间碎片查看索引状态和表空间使用情况定期重组索引回收碎片空间临时表空间爆满大量排序或哈希关联操作查看临时表空间使用率扩容临时表空间优化SQL减少排序5.1 关于“锁等待”的一个独立坑月结最常见的卡死场景就是锁等待。但很多人排查时陷入一个误区看到enq: TX - row lock contention就去杀会话结果发现杀完另一个又卡住没完没了。正确做法是先找出锁的持有链谁锁了谁根因是谁。我见过一个典型案例月结卡死是因为一张业务单据审批流程没有关闭某个用户在前台界面上挂了一个未提交的事务导致后台月结任务被无限期阻塞。这种情况下杀后台任务是没用的找到根因会话并处理才是正解。5.2 关于“临时表空间”的一个补充21亿数据的月结涉及大量排序、去重、关联操作临时表空间使用量经常突破预期。我踩过的一个教训是不要只看临时表空间的当前使用率还要关注历史峰值否则月结峰值一上来就直接“临时表空间不足”报错整个流程崩溃。我的做法是提前做一轮压测把月结数据量放大到平时的1.5倍观察临时表空间的最大消耗量然后按这个峰值的1.5倍去配置临时表空间大小。6. 从21亿月结优化延展出的通用经验项目收尾后我把这套方法论沉淀下来后来在几个数据量没那么大的企业ERP系统迁移、月结提速项目里继续复用验证了这套思路的通用性。6.1 月结优化的核心永远是“业务理解”先行首先不去理解财务月结的业务逻辑就去调优大概率是瞎忙活。比如你辛苦优化了一条SQL结果发现这个SQL在月结流程里根本不在关键路径上那优化了也白优化。所以我在每个项目里的第一件事都是拉通财务月结的完整流程图找出每一步的数据来源、数据量级、依赖关系然后再谈技术手段。6.2 “增量化”思想适用于绝大多数大规模批处理不只是财务月结任何大规模批处理场景——存货核算、成本分摊、薪酬计算、报表汇总——都适用“平时代算、期末增量”的通用思想。本质都是避免在关键时点做大量重复计算。如果你现在面临的问题不是月结而是某个天天跑的批量任务越来越慢不妨也往这个方向想想是不是可以每天只处理增量数据而不是每天全量重算6.3 永远给月结留Plan B优化做得再好也架不住偶尔的业务数据异常、数据库抖动、甚至存储故障。月结是财务披露的生命线必须有Plan B。我最后在系统层面做了两层兜底月结检查点机制把月结流程拆成多个检查点每个检查点记录已完成状态流程中断后可以从最近检查点续跑不用全部重来备用窗口预留月结期间预留独立的维护窗口如果主流程出问题立刻切换到备用环境或备用时间窗口运行这两层兜底成本不高但在关键时刻能救命。有一次生产环境存储故障导致月结中断就是靠检查点恢复机制在2小时内完成了续跑没有影响财务出表时间。如果你正在为月结头疼建议先把检查点机制做上再谈性能优化。
