往期回顾
迷谷悟道
书成惊四座，心法解千愁。
老友诉新苦，性能遇险阻。
迷谷寻出路，道在林中悟。
万法皆自然，新篇待启航。
1
书成惊四座，心法解千愁
书接上回。帆哥那句——“现在……唉，不少棘手的数据库问题让我们头皮发麻啊！”——像一颗投入湖面的石子，在我心中激起的波澜。
自从重心转向研究院后，我已经很少像以前那样，直接扎到一线去“救火”了。但听到老战友遇到难题，我心里那股熟悉的“技术瘾”又有点蠢蠢欲动。他们遇到的，会是怎样的新挑战呢？
正当我准备细问时，一个兴奋的声音抢先一步，从旁边炸响：“哥！我必须得敬你一杯！”
我转过头，原来是阿伟，他端着酒杯，满脸激动。“我刚得知，《收获，不止Oracle》稳居京东、当当网数据库畅销榜的榜首，同时豆瓣评分高达9.3分，简直是奇迹啊！”
此时有人带头鼓掌，把不少其他桌的同事都吸引了过来。
我有些不好意思地笑了笑，连连摆手：“过奖了，只是分享一些个人经验罢了。”
我嘴上这么说，但心里那份被认可的喜悦，如同杯中的美酒，温暖而醇厚。
“哥，我们刚才还在分析，你这本书为什么能这么火。”阿伟继续说道。
我好奇地问道：“为什么？”
阿伟推了推眼镜：“市面上大部分技术书，都在教我们‘what’和‘how’。但你的书，重点落在‘why’，在讲你解决问题时的‘思考过程’和‘方法论’。而且用讲故事的形式把枯燥的原理，变成了我们能感同身受的破案经历。所以，这本书最成功的地方，在于它卖的不是冷冰冰的‘技术’(术)，而是有温度的‘心法’(道)。这一点，太难得了...”
2
老友诉新苦，性能遇险阻
酒过三巡，之前话题被阿伟打断的帆哥，端着酒杯又走了过来，脸上带着一丝苦笑，：“大师，你的书和心法，确实解决了我们Oracle时代的很多顽疾。但问题是，时代开始变了，我们现在遇到的新麻烦，比以前更头疼了！”
我不解地问道：“到底是什么问题，让你们这么为难？”
他开始大倒苦水：“我负责的业务线开始做‘去O’的尝试，如今线上跑的数据库，除了Oracle外，还引进了各种开源数据库、国产数据库、专用数据库等等，简直是‘百家争鸣’，需要我们学习的太多了！而且各家厂商的支持力度和技术水平参差不齐，一出问题，解决起来就很麻烦。所有问题里，最头疼、占比最高的，还是性能问题；而所有性能问题里，绕来绕去，最后发现80%又回到了SQL问题上。”
帆哥的这番话，瞬间让整个餐桌的气氛从“庆功”转为了“共情”。大家纷纷点头附和，七嘴八舌地补充着各自项目中遇到的类似困境。显然，这已经成了“后Oracle时代”一个普遍的痛点。为此，我也陷入了沉思，一时也不知道该如何解决。
3
迷谷寻出路，道在林中悟
宴会结束了，这个问题依然一直在我的脑海中盘旋。为排解心中困惑，周末我独自一人去郊外野山转转。我想，或许换个环境，能让混沌的思绪，找到一丝清明。
此时，树影越来越密，光线越来越暗。我低头看向手机，发现屏幕上赫然出现刺眼的“无服务”标志，而且也快没电了。一种与世隔绝的孤独感，混合着对未知的恐惧，扑面而来。
我强迫让自己冷静下来。越是危急时刻，越不能乱阵脚。我没有立刻慌不择路地去盲目尝试，而是先停了下来。
第一步：判断“整体”方位。我深吸一口气，开始运用最普适的自然法则：抬头，观察太阳的位置，判断大致的方向；低头，观察树木阴影的朝向，再次确认；侧耳，倾听远处是否有水流声，那是通往下山方向的信号；感受，脚下地面的坡度，是向上还是向下……我必须先弄清楚，我现在大概在山的哪个区域，整体的下山方向在哪里。
第二步：寻找“核心”路径。在确定了大致的下山方向后，我开始审视眼前的几条可能的“路”。哪条路，能让我以最少的体力消耗（工作量），最快地接近山脚？我放弃了那些看起来平坦但可能绕远的“路”，选择了一条虽然陡峭、但方向最正确的下山小径。因为我知道，此刻，最高效地降低海拔，才是走出困境的核心。
第三步：审视“必要性”。沿着这条“路”走了一段，我又遇到了“岔路”。这时，我没有盲目选择，而是再次停下来思考：我真的有必要走这条“岔路”吗？它看起来是捷径，但会不会通向悬崖或者更密的丛林？我再次运用“整体”判断（太阳、坡度），最终决定，放弃这条不确定的“捷径”，继续沿着那条虽然慢、但方向明确的“主路”走下去。天黑在即，要果断行事。
就这样，依靠者“先整体判断方向，再寻找关键路径，并不断审视路径必要性”这套方法。最终，我安全了！
那一刻，虽然身体疲惫，但我的内心，却从未如此澄澈和兴奋。因为，我不仅找到了下山的路，更找到了解决帆哥他们那个“性能新困”的钥匙！
4
万法皆自然，新篇待启航
下山的“道”与SQL优化的“道”，在这一瞬间，竟是如此的相通！
帆哥他们之所以觉得SQL问题层出不穷，不就是像我刚才一样，一上来就迷失在了这片数据库百家争鸣的密林里，只盯着眼前的慢SQL（这条小路），却忘了先抬头看看太阳（系统全局），搞清楚方向吗？！”
没错！无论你用的是什么数据库（走的是什么路），优化的第一步，永远是‘先整体、后局部’！先看清全局瓶颈（我到底在山的哪个方位？），再去找那条真正的‘罪魁祸首’SQL（正确的下山路）！
那找到了问题SQL（确定了下山方向）之后呢？如何走得更快？下山，不就是要用最少的步数（体力耗尽、天黑在即）到达山脚吗？那SQL呢？衡量它‘工作量’的那个最核心、最通用的指标是什么？——逻辑读！Logical Reads！抓住它（选择最高效降低海拔的路）！想尽一切办法减少它！这才是通往性能巅峰的‘最短路径’，管他什么Oracle、什么MySQL、什么ABCD数据库，都一样！”
“还有！还有刚才那个“岔路”！我为什么没走？因为我停下来想了：‘真的有必要走这条路吗？’——对！SQL优化，也要这样‘反思’啊！这条SQL，真的有必要执行吗（真的要走这条看似捷径的岔路吗）？真的有必要执行这么多次吗（真的要在这条路上来回折返跑吗）？在确认了它的‘必要性’之后，才去想‘如何让它跑得更快’（如何优化路径）！这不就是那三个字——少！做！事！吗？！”
“先整体、后局部”、“抓核心指标（逻辑读）”、“审视必要性（少做事）”！
几天后，我向大家分享了自己这套“迷谷悟道”。帆哥听了激动地站起身来：“大师，再来一本新书吧。就叫《收获，不止SQL优化》！”
有道理，有道理！这不比聚焦Oracle的《收获，不止Oracle》，这可是跨越所有门派的“通用心法”。太好了，太好了！
不过，当时的我，还是太天真了，殊不知，这，远比上一本书要艰辛的多！
未完待续…
不迷路