工作总结
发表时间：2026-03-14技术咨询个人工作总结。
五月那个周一的早晨，电话响得急。气象台的同事说预警发布系统慢了，数据库响应要十几秒，马上要发暴雨预警，时间耽搁不起。我抓起笔记本往外赶，路上让同事先查慢查询日志。
到现场，CPU跑满，连接数正常，磁盘IO平稳。监控看一圈，没发现明显异常。正准备重启应用服务器，余光扫到另一个屏——某个数据文件的读取频率曲线突然翘了个小尖。顺着这个指标追下去，发现是数据库统计信息过期了，优化器选了全表扫描。
那条SQL是我去年重构时写的，用了动态SQL适配多种查询条件。测试环境数据量小，跑得欢。生产跑了一年，数据翻了几番，统计信息没自动更新，就栽了。
手动更新统计信息后系统恢复，但问题没完。我翻了自动更新配置，阈值设得太高——数据变化量不到20%不触发，而我们的增量每次只有5%左右。我改成5%，并把更新频率从每天一次调成每次批量导入后触发。至于那条SQL，我加了强制索引的提示，但也多写了一段逻辑：如果强制索引后执行时间还超阈值，自动回退到普通查询，同时发告警。稳妥比完美重要。
这件事教会我一件事：别太信“默认配置”。文档里写“自动更新”，不代表它会在你需要的时候更新。后来再看别人的故障报告，我都会想：这次的问题，往前推两步，监控能提前发现吗？代码里还有哪些依赖默认行为的地方？
下半年帮一个科研机构做数据归档。十五年观测数据，要存还要查得快。按常规会分区，但他们查询经常跨年份、按设备类型筛选，分区表优势不大。我建议用列存引擎，配合物化视图预计算。
方案听起来不复杂，落地全是细节。我带着笔记本，跟他们业务人员坐了三天，看他们查什么、怎么查。他们口口声声说“这个查询每天跑”，我翻历史SQL日志，发现其实三天才跑一次——他们说的“每天”是工作日，周末不看。还有一次，业务主管指着屏幕说“就这几个字段，天天看”，结果日志显示他们查的全是别的字段。后来只好对着几十条真实SQL一条条标，才把高频查询模式摸清楚。
物化视图设计了三版。第一版按天刷新，数据量太大，跑一次要半小时。第二版改成增量刷新，但业务说凌晨的数据要实时可见，增量刷新滞后不行。第三版折中：核心视图每小时全量刷新，非核心的用增量，加一个手动触发按钮，临时要最新数据可以点一下。上线后，跨五年查询从几分钟降到几秒，运维同事说月底报表再也不用熬夜了。
应急指挥系统改造那个项目，老系统用了十年，耦合成一团乱麻。领导想推倒重来，我说风险太大，不如“绞杀式重构”——新功能用微服务写，通过网关引流，慢慢替换老模块。听起来有道理，拆起来全是坑。
选了三个非核心模块试点。其中一个模块，老系统一张表读写，新服务要拆成两个库。数据一致性怎么办？业务说可以接受几分钟延迟，我们就没用分布式事务，用本地消息表加定时任务补偿。代码我写了三遍：第一遍太复杂，自己都绕晕了；第二遍死锁频发，回滚了好几次；第三遍简化流程，用消息表的状态机控制，稳定了。上线后观察两周，补偿任务每天跑一次，对账没出过错。
那段时间经常加班到半夜，有次改完代码，看窗外天都亮了。同事递来红牛，说“这破模块总算搞定了”。后来系统上线，白天也能发布新功能，再也不用凌晨两点守着。雨后的早晨，客户打来电话，说“这次快了，谢谢”。就这一句，觉得值了。
年底我把这一年遇到的故障和优化写成技术简报，发在团队群里。第一个案例就是数据库统计信息那个，写了排查过程、根因、改进措施。新来的同事看了，说“原来你也有踩坑的时候”。我说踩坑不要紧，爬起来记得做个标记。上周他遇到类似问题，半小时就解决了，发消息说“多亏你那篇简报”。
这一年最大的体会是：技术咨询不是卖方案，是和客户一起解决问题。问题有急有缓，急的时候先止血，缓的时候挖根子。代码写得好是本事，但代码跑得稳、查得快，才是真本事。明年打算把手里几个老项目的技术债理一理，监控做细一点，让问题在变成故障前就暴露出来。
前几天路过机房，听见两个同事讨论一个优化方案，用的思路跟我去年写的简报一样。我站在门口听了一会儿，没进去打扰。
-
需要更多的工作总结网内容，请访问至：工作总结
