技术人生——第12集：思想破晓，功能相随
梁敬彬 梁敬弘约 8 分钟往期回顾
思想破晓
盛名生隐忧，回首觅真经。
巧手偷天日，作弊换光阴。
分身化万影，聚力踏千军。
运筹帷幄间，错峰定乾坤。
1
盛名生隐忧，回首觅真经
书接上回。
在分享会上，帆哥那句“大师，再来一本吧！” 像一颗投入平静湖面的巨石，激起了千层浪。同事们纷纷附议，热烈地讨论着这个提议。
那一晚，我是在一种混杂着兴奋、感恩和压力，回到家的。
关上门，夜深人静，帆哥的提议在我脑海里反复回响。我铺开一张白纸，试图为这本众望所归的新书搭建一个框架。 我想把之前在迷谷里悟出的那套通用心法写下来。 那次死里逃生的经历，让我明白了优化的真谛其实就三点：先整体后局部、抓核心指标、审视必要性。 如果要更精练的概括，其实就是大道至简的三个字——少做事！
但当我要把这三个字落成文字时，却发现脑中一片空白。
恰逢第二天出差去北京，见到弟弟，我忍不住倾诉了这份焦虑。 弟弟听完，笑了：哥，大家想听的，是你怎么不拘一格解决问题，你不需要刻意去证明你的思想，你只需要去再现那些诞生了思想的真实场景！把你的那些故事写下来，道理不就在其中了吗？想不了太远，先做再说。
一语惊醒梦中人！我不需要凭空创造，我只需要忠实地再现。
那一刻，窗外忽然墨云压城，雷声滚滚，紧接着暴雨倾泻，屋内瞬间停电。这场景，瞬间开启了我记忆的闸门。我惊讶地发现，原来少做事这套心法，早就藏在我当年的野路子和小聪明里了。
2
巧手偷天日，作弊换光阴
我想起了多年前，那个电闪雷鸣、风雨交加、全城停电的下午那天，我“作弊”了。
当时的我，刚从研发转成DBA，就遇到一个不小的挑战。我的领导每天雷打不动地，要在中午前看业务统计报表。这些报表逻辑复杂且涉及的数量很大，所以每次查询都很慢。 在尝试了各种SQL调优都收效甚微后，我开始思考： 领导要的是昨天的数据，这是一个历史确定的结果。既然结果已经定了，我为什么一定要在他查询的那一刻才去计算呢？这有必要吗？
于是，我写一个数据库作业Job，让它在每天凌晨两点，系统最空闲的时候，就悄悄地把结果算好。
--凌晨2点定时执行的SQL（伪代码）CREATE TABLE report_result_daily ASSELECTbiz_type,SUM(amount) AS total_amount,COUNT(*) AS total_countFROMmassive_biz_tableWHEREcreate_time >= TRUNC(SYSDATE) - 1AND create_time < TRUNC(SYSDATE)GROUP BYbiz_type;
然后，我改造了报表程序，让它不再执行那个漫长的复杂查询，而是直接从我新建的这张小小的“结果表”里取数。
-- 白天老板查询的SQL，0.5秒出结果SELECT * FROM report_result_daily;
庆幸的是，领导不仅没怪罪，反而高度认可了这个用空间换时间的思路。这，就是少做事心法中的审视必要性。
你是不是猜到什么了？
是的，不久后，数据库厂商正式推出了这个功能，并取了一个非常学术的名字——物化视图 Materialized View。我忍俊不禁，内心涌起一阵莫名的激动。看来，我的野路子跑在了厂商的前面。
思想破晓，功能相随。在官方功能诞生之前，我就已经用土办法实现了它！这是我第一次品尝到思想超越功能的快感。
我提笔快速记下了这个故事，手感渐热。
哥，还有呢？ 弟弟在一旁提醒，你这种在业务层手动实现数据库特性的事，可不止这一件吧？比如并行？
对，并行！ 顺着这个话头，我的思绪瞬间飞到了当年那场惊心动魄的省集中战役。
3
分身化万影，聚力踏千军
就在大家一筹莫展之际，同事石头忽然指着监控屏幕说了一句：奇怪，程序跑不动，怎么机器的CPU大半都闲着？
这句话一下子击中了盲点！ 我们陷入了思维误区，只盯着数据库内部的SQL在纠结，却忘了抬头看一眼外部的资源。守着多核CPU这百万雄师，却只派了一支小分队（单进程）去战斗，怎么可能不慢？
当时，数据库内部并无并行功能。不过这可难不倒我们，咱们就自己动手造一个！ 我们当即决定，把战场从数据库内部移到外部应用层。我们写了一系列脚本，将数亿条数据切分成几十份，然后同时启动几十个进程，围殴这些数据。
#!/bin/bash# 调度脚本核心逻辑（伪代码）TOTAL_KEYS=$(get_all_keys_from_source_table)# 设定我们要开启的并行度（比如50个进程同时跑）PARALLEL_COUNT=50# 动态计算每个批次的大小（上亿数据 / 50 = 每份的大小）CHUNK_SIZE=$((TOTAL_KEYS / PARALLEL_COUNT))# 按计算好的大小进行切分KEY_CHUNKS=($(echo $TOTAL_KEYS | xargs -n $CHUNK_SIZE))for chunk in "${KEY_CHUNKS[@]}"; do# 将每一大批key作为参数，后台启动一个独立进程run_oracle_procedure "$chunk" &done
这一招人海战术，立竿见影。迁移瞬间从5小时杀进3小时。众人齐力，酷！
紧接着，我们一鼓作气，发现内存利用率也不高，于是又利用缓存将内存榨干到极致。最终，耗时定格在2.5小时，完美通关！
你是不是又猜到了什么？
是的，不久后数据库厂商们也想通了这一点，推出了大名鼎鼎的并行查询Parallel Query功能。而其核心思想，竟与我当年那个被逼出来的野路子如出一辙。
思想破晓，功能相随。在生产压力之下，我们的思想一直走在厂商的前面。这也正是少做事心法中抓核心提效的生动体现。
带着一点小小的自豪感，我挥笔在纸上记录下了这个“人海战术”的经典案例。
4
运筹帷幄间，错峰定乾坤
至此，我开始思如泉涌。 那些曾经被我视为野路子的经历，此刻正如珍珠般一颗颗浮现。我继续提笔在纸上记录下了第三个故事。
XX地市顺利集中后，系统一到半夜就告警频繁，资源不堪重负。因为财务报表、批量跑批、数据备份，全都挤在了凌晨这个黄金时间执行，互相打架。
此时，技术优化收效甚微。 就在大家盯着满屏红色的CPU报警，一筹莫展时，研究院专家阿忠忍不住抱怨了一句： 哎呀，这哪是跑批啊，这简直就是早高峰的二环路，所有车都挤在这个点上，能不堵死吗？
早高峰？说者无心，听者有意。这两个字像一道闪电划过我的脑海。 对啊！既然是早高峰，我们治理堵车的办法，从来不是把马路无限修宽，而是——错峰出行！ 既然资源有限，为什么非要让财务报表、备份和跑批挤在同一个车道里厮杀？为什么不能给它们把时间错开？
思路一变，天地宽。 我立刻拿着这个方案去求助领导，最终在领导的协调下，制定了一张严格的任务时刻表： 财务报表提前到晚上10点；数据备份推迟到凌晨4点；核心跑批牢牢占据凌晨1-3点这个最核心的空窗期...
仅仅通过这种手动资源调度，系统的午夜拥堵瞬间迎刃而解。
你是不是又又猜到了什么？
是的，不久后，数据库厂商们也为这种错峰填谷的思想，推出了一个官方的功能，叫资源管理器 Resource Manager。
思想破晓，功能相随。这不就是少做事心法中的先整体后局部吗？站在全局视角，让不必要的争抢少一点。
……
窗外的雷雨终于停了，阳光穿透云层，洒在我的书桌上。 我手中的笔在纸上飞快地记录着，好一个畅快淋漓！看着纸上这三个鲜活的故事，自信涌上心头。
我们做预计算时，厂商没有物化视图功能。
我们跑多进程时，厂商尚未推出并行查询。
我们错峰规划时，厂商不曾有资源管理器。
我突然明白，这些故事不仅是对少做事心法的验证，更说明了一个道理：并不是因为有了某些功能，我们才解决了问题，而是我们先有解决问题的思想，后有这些依据思想而固化的功能。
真正的专家，不仅仅是说明书解读者，更是未来书写者。我们用思想在黑暗中探索，当思想率先破晓，官方的功能自然会紧紧相随。
正当我准备收笔时，弟弟忽然感叹了一句： “哥，依我看，说到少做事的最高境界，还得是陈总吧。”哦，是啊，陈总。 如果不曾遇见他，我又怎会拥有后来那“敢于质疑，手起刀落”的勇气？
我的思绪再次飞扬……
未完待续…