工作总结

【精选】产品精算岗个人工作总结。

今年二季度末那场故障，到现在我还记得清清楚楚。

那天下午三点多，正准备下班，运维群里突然炸了——利源分析系统跑了一个半小时还没结束，核心调度卡在某个环节，所有报表都卡着出不来。登录服务器一看，CPU直接拉满，临时表空间快写爆了。这简直难以置信，这套基于存储过程的批处理跑了三年，从来没出过这种幺蛾子。我赶紧手工Kill掉进程，开始排查。

先用show processlist看了一眼，发现有一个查询一直在Copying to tmp table状态。再翻出那个核心存储过程，把最长的关联查询拎出来explain了一下——好家伙，rows那列显示要扫描两千多万行，Extra列里明晃晃写着Using temporary; Using filesort。当时心里就凉了半截：这是临时数据把磁盘撑爆了。后来翻数据表的统计信息才发现，新接入的那个产品线，因为缴费方式复杂，保单状态表半年膨胀了五倍，但我们的关联查询还跟三年前一样，用着最原始的嵌套循环。让人深感无奈的是，这种问题在测试环境根本复现不出来——测试库才几十万条数据，跑得飞快。

怎么处理？说实话，那晚我没敢上来就大改架构，先得让报表组明天早上能交差。

第一步，临时止血。我分析了一下，最拖慢速度的就是那张千万级的保单状态表。与其重写整个存储过程（至少两小时，等不起），不如单独给这个产品线开个“小灶”。我直接写了个中间表：insert into temp_policy_status select ...把当期的保单状态按产品线拆出来，先聚合、去重，把需要反复计算的那些字段提前算好。然后用这个临时表去替换原查询里的那张大表，关联逻辑从两层嵌套循环变成了一层简单的join。虽然多写了两张表，IO开销大了点，但总运行时间从预计的三个多小时压缩到了40分钟。凌晨一点多，报表终于跑出来了。

第二天开始做根治。我把整个处理流程画了张图，发现至少有四个地方存在重复扫描：同一个保单在不同时间点的状态，被反复读了七八次。这纯粹是在浪费资源。最后决定把纯SQL处理改成SQL加内存计算的混合模式——用Python写了个轻量级调度脚本，把需要反复读取的基础数据加载到内存里，然后用批处理逐批计算。你懂的，内存操作比磁盘IO快了一个数量级。改完再跑，20分钟搞定。

这之后我还干了一件事：在关键SQL后面塞了个select sleep(0.1)打时间戳，把执行日志写到文件里，又让运维帮我在zabbix上加了个监控。这样下次哪个环节开始变慢，我能提前知道，不用等跑死了才冲进机房。

这事儿过后，我养成了几个习惯。

赵老师教案网（ZJAN56.COM）小编好专题推荐:
• 保险精算评估岗工作总结 | 保险精算分析岗工作总结 | 精算工作总结 | 个人工作总结 | 产品精算岗工作总结 | 产品精算岗工作总结

一个是遇到问题先看数据分布。以前排查故障，总习惯盯着代码逻辑找bug，现在第一反应是先看看数据量长成什么样了——同样的代码，数据翻五倍可能就不是bug，而是架构问题。

另一个是做设计前得先问问业务预期。当初搭这套系统时，产品线的同事说一年也就几十万单，我留了200%的余量，觉得够够的。结果人家半年就卖了五倍。现在回过头看，当时要是多问一句“你们明年打算冲多少”，也不会踩这个坑。说白了，技术瓶颈往往不在技术本身，而在业务预期上。

现在带新人，我常让他们写代码之前先摸摸数据：去生产环境select count(*)看一眼，explain一下，心里有数再动手。别像我当年一样，等数据长成怪兽了才追着打。

推荐阅读: 【精选】产品精算岗个人工作总结 保险精算评估岗工作总结(精选十一篇) 保险精算评估岗工作总结(精品7篇) 保险精算分析岗工作总结（收藏9篇） 最新保险精算分析岗工作总结（通用十二篇） 工作个人工作总结(精选十四篇)

更多精彩的工作总结，欢迎继续浏览：工作总结

热门标签: 精算评估工作总结 科研个人工作总结 美术个人工作总结 出纳个人工作总结 行政个人工作总结 幼师个人工作总结

本文来源：//www.zjan56.com/jiaoanziliao/166455.html