梁敬彬梁敬弘兄弟出品
往期回顾
技术人生——第1 集： 机械出身，我不机械
技术人生——第2 集： 膨胀自信，午夜惊魂
技术人生——第3 集： 穿越救赎，因祸得福
技术人生——第4 集： 便捷惨案，泣血蜕变
技术人生——第5 集： 剑破冰山，畅行无阻
技术人生——第6 集： 收获惊喜， 不止O记
技术人生——第7 集： 一本书籍，一所小学
技术人生——第8 集： 打破枷锁，火箭跃升
技术人生——第9 集： 拓荒立制，创研究院
技术人生——第10集：幸运敲门，新曲线成
技术人生——第11集： 收获不止，SQL优化
1. 知易行难，大道至简
小方那句“大师，再来一本吧！”，像一颗投入平静湖面的巨石，在庆功宴的餐桌上，激起了千层浪。同事们纷纷放下酒杯，开始热烈地讨论、并附议这个“疯狂”的提议。
那一晚，我是在一种混杂着酒精、兴奋和巨大压力下回到家的。
关上门，夜深人静，白天的喧嚣散去，小方的提议和同事们期待的眼神，却在我脑海里反复回响。我铺开一张白纸，试图为这本“众望所归”的新书，搭建一个框架。但我的脑中，却和这张白纸一样，一片空白。
我发现，在酒桌上高谈阔论，和真正坐下来体系化地输出一本专著，完全是两码事。要把“性能之道”这种形而上的“思想”，用文字清晰地表达出来，实在是太难了。知易行难，那一刻我体会得淋漓尽致。
之前积累的成功经验，此刻反而成了我最大的枷锁。我怕写不好，会辜负所有人的期待；我怕写不出来，会搞砸自己“畅销书作者”的名声。一种前所未有的创作压力，让我再次有了“打退堂鼓”的念头。
恰逢第二天出差去北京，又有机会和我弟探讨了。一见面我就把我的担忧告诉他：“所有人都觉得我行，但我自己知道，我可能……真的不行。境界这东西，虚无缥缈，我怕我写砸了。”
弟弟听完，笑了：“哥，你忘了你的价值是什么吗？小方他们为什么会提出这个建议？因为他们想听的，不是你讲‘大道理’，而是想看你当年是怎么不拘一格解决问题的。你不需要过于纠结思想的定义，你只需要去再现那些诞生了这些思想的真实场景！把你的那些故事写下来，道理，不就在其中了吗？”
他一语惊醒梦中人！我需要的，不是凭空创造，而是忠实地“再现”！我的思路，豁然开朗。
2. 空间换时间的“作弊”
此时外面天忽然暗下来，天雷滚滚，响彻天地，然后屋内忽然停电了。这让我忽然想起多年前的一天，也是这样的骇人场景。也就是在那一天，我“作弊”了。【参考链接：“作弊”？NO！】。
当时的我，刚从研发转成DBA，就遇到一个不小的挑战。我的领导每天雷打不动地，要在中午前看业务统计报表。这些报表逻辑复杂且涉及的数量很大，所以每次查询都很慢。而我也时常被领导叫到办公室：“小伙子，报表怎么这么慢，你什么时候可以处理好啊？”这种压力一直让我有一种喘不过气来的感觉。
在尝试了各种SQL调优都收效甚微后，我开始反向思考：老领导要的是“昨天”的数据，这是一个“历史确定”的结果。既然如此，我为什么一定要在他需要的时候，才开始计算呢？
于是，我写一个数据库作业（Job），让它在每天凌晨两点，系统最空闲的时候，就悄悄地执行那个复杂的查询。
-- 凌晨2点定时执行的SQL（伪代码）
CREATE TABLE report_result_daily AS
SELECT
biz_type,
SUM(amount) AS total_amount,
COUNT(*) AS total_count
FROM
massive_biz_table
WHERE
create_time >= TRUNC(SYSDATE) - 1 AND create_time < TRUNC(SYSDATE)
GROUP BY
biz_type;
然后，我改造了报表程序，让它不再执行那个漫长的复杂查询，而是直接从我新建的这张小小的“结果表”里取数。
-- 白天老板查询的SQL，0.5秒出结果
SELECT * FROM report_result_daily;
第二天，一声惊呼声从老板办公室传来：“哇，怎么这么快！”我很快又被他叫进办公室，他当时震惊的表情，我至今记忆犹新。
我正准备解释我的优化思路，天忽然暗下来，打起了雷，声音大的吓人，随后停电，办公室传来了女同事的尖叫。我心想，完了，我这还真是作弊啊，老天爷在警告我啊。
不过庆幸的是，领导非常认可我这件用“空间”换“时间”的事，还在会上表扬了我。希望大家向我学习，在工作中要加强对业务场景的理解。
不久，数据库厂商正式推出了这个功能，并为我当年这个“作弊”的方法，取了一个非常学术的名字——“物化视图”（Materialized View）。
3. 众人拾材火焰高
“想什么呢？” 我弟声音把我从回忆中唤回来。在听完了我的回忆后，我弟笑着提醒我，说我这样在业务层面实现了数据库的新特性，可远不止一次哦，比如还有并行和资源调度。
哦，对啊！我弟的话很快勾起了我的另外一段回忆。当时，电信系统省集中，我和同事石头被派往用户数规模最大的泉州，支撑泉州数据往省公司迁移工作。由于整体上线的时间很紧张，留给数据迁移的工作不过短短3小时，我们演练了多次，尝试了各种办法，从开始的十多个小时缩减到5小时后，再也无法提升了，陷入了困境。
当时，大家都聚焦在“如何优化各种迁移程序效率本身”，我们把那几百行代码翻来覆去地研究，但效果甚微。就在大家一筹莫展之时，石头忽然发现，迁移演时机器的资源利用率似乎很低，提出如果利用率能提升，是不是就能让数据迁移提速。
一语惊醒梦中人，对啊，我们为什么不可以让这些存储过程用到更多的资源呢？于是，我们把目光从数据库内部，移到了数据库的外部——应用层。写了类似如下的调度脚本。
Bash
#!/bin/bash
# 调度脚本核心逻辑（伪代码）
TOTAL_KEYS=$(get_all_keys_from_source_table)
KEY_CHUNKS=($(echo $TOTAL_KEYS | xargs -n 10000)) # 每10000个key作为一批
for chunk in "${KEY_CHUNKS[@]}"; do
# 将每一批key作为参数，后台启动一个独立的数据库处理进程
run_oracle_procedure "$chunk" &
done
这个脚本的核心，就是将上亿条数据，均分成几十份，然后，同时开启多进程，让每个进程都去处理那一小份数据，性能提升的原理很简单，从单个进程干活变成多个进程干活，众人拾材火焰高。
结果我们发现进程有了数倍的性能提升，于是开始对大量存储过程都做了这样的改造，结果时间从5小时很快缩减到了接近3小时。接着，我们又发现，机器的内存利用率也不高，于是我们将大量的结果直接缓存到内存中，将内存的资源用到极致。最终迁移时间缩减到2小时半，终于完美完成任务。
正如你可能猜到的那样，多年以后，数据库厂商们也想通了这一点，纷纷推出了“并行查询（Parallel Query）”功能，其核心思想，与我当初那个“野路子”，竟如出一辙。
4. 错峰出行有规划
泉州顺利集中后，其他地市也就顺风顺水了，最终省集中项目圆满完成。不过，当时的系统，一到半夜，CPU就全线飙红，各种任务互相“打架”，告警邮件像雪片一样飞来。因为财务的月度报表、业务的批量跑批、数据的备份任务，全都约定俗成地，挤在了凌晨这个“黄金时间”执行。
咋办？开始我们也没辙，只能不停的优化，让SQL尽可能的快一些，希望以此来缓和压力，不过收效甚微。
最后，我们不得不求助于领导，在领导的授权下我们组织不同的业务部门进行沟通探讨，最终协调出一张“任务时刻表”，拉着各个业务部门负责人，让他们“错峰出行”——财务报表提前到晚上10点；数据备份推迟到凌晨4点；核心业务跑批，则牢牢占据凌晨1点到3点这个最核心的时间窗口。
仅仅是通过这种“手动资源调度”，系统的“午夜拥堵”就迎刃而解。是的，你又猜对了，数据库厂商们，也为这种“错峰填谷”的思想，推出了一个官方的功能，叫做“资源管理器”（Resource Manager）。
想到这些过往经历，我长舒一口气。我更加坚信，优化的尽头，是思想。真正的专家，不是一个精通所有工具的“工匠”，而是一个能洞察问题本质，并为之创造工具的“思想家”。
此时，乌云散去，雷电停止，电也恢复了。我向弟弟要来了笔和纸，快速将刚才回忆的内容写出来，这可是新书的绝好案例啊。最后我总结到思想两字时，弟弟忽然说道：说到思想，你最应该感谢的是陈总吧。
哦，是啊。我的思绪再次飞扬…
未完待续…
技术人生——第13集：回归本源，大道至“减”