抓住两点堵住一个漏洞的笑话

```html

老张蹲在机房角落，手指戳着屏幕，两点嘴里嘟囔：“两点，堵住洞就两点。个漏堵住那个漏洞，笑话系统就能跑。抓住”他说的两点“两点”是数据库连接池的两个参数——maxActive和maxWait。一个管最多开多少连接，堵住洞一个管等多久算超时。个漏听起来简单，笑话但那天晚上他熬到凌晨三点，抓住就因为这两点没掐准，两点线上服务每隔二十分钟崩一次。堵住洞

事情是个漏这样的：某个电商后台，订单导出功能总在高峰期卡死。笑话日志里一堆ConnectionPoolTimeoutException。老张第一反应是连接池太小，把maxActive从50调到200。结果更糟——数据库先扛不住，连接数爆了，DBA打电话骂人。他缩回去，又把maxWait从5000毫秒改成1000毫秒。这次不崩了，但导出请求十有八九直接报错，用户投诉翻倍。

“抓住两点”这说法，最早是隔壁工位老王提的。老王干了十五年运维，口头禅是“别整那些虚的，抓两点就行”。那天他端着保温杯晃过来，瞅了一眼老张的屏幕：“你光调大没用。maxActive要配合maxWait一起看。连接池像食堂打饭窗口，窗口开多了，厨师忙不过来；窗口开少了，队排到门外。你得算平均打饭时间，再定开几个窗口、排多久队算离谱。”

老张听进去了。他翻出过去一周的监控数据：平均每个导出请求持有连接1.8秒，峰值并发请求120个。他拿纸笔算：如果maxActive设成150，maxWait设成3000毫秒，理论上能扛住。改完上线，果然不崩了。可第三天又出问题——某个慢SQL跑了15秒，把连接全占住，后面的请求等3秒就超时。漏洞不在参数，在SQL本身。

笑话就在这儿：老张折腾两天，以为抓住了“两点”——调参数，结果真正的漏洞是第三点——那个select * from order_detail where create_time like '%2024-05%'。like前面加百分号，索引直接废掉。全表扫描，每扫一次占住连接十几秒。连接池再大也白搭。

后来老张把这事当段子讲给新人听。新人问：“那到底抓哪两点？”老张嘿嘿一笑：“第一点，别信‘两点’这种鬼话。第二点，去查慢查询日志。”至于那个漏洞，他补了索引，又加了个缓存。系统稳了，老王保温杯里的枸杞也终于不用泡到发白。

我见过太多类似的“两点论”。有人调JVM堆大小，有人改线程池队列，有人加机器。都是抓两点——调大、调小。可漏洞往往藏在第三点：一段烂代码、一个没建的索引、一次没清的空指针。抓两点容易，因为参数就在那儿摆着，改个数字重启就行。堵漏洞难，因为得读代码、看日志、承认自己之前想错了。

老张现在带团队，开会时总说：“别急着抓两点。先看看那个漏洞长什么样。”说完自己先笑。底下人跟着笑，笑完老老实实去翻监控。这笑话不高级，但管用。