凌晨两点，量查我盯着屏幕上那条跑了四十分钟还没结束的量查SQL，咖啡杯沿留下一圈干涸的量查渍。这查询要扫三千万行，量查就为了找出二十个符合条件的量查用户ID——典型的“用大炮打蚊子”。后来我把单条查询拆成十批，量查每条只扫三百万行，量查总耗时从四十分钟降到两分半。量查这就是量查批量查询的意义：不是炫技，是量查保命。

批量查询的量查核心就八个字：缩小范围，减少往返。量查数据库最怕的量查不是数据多，而是量查你一次要的太多。好比去图书馆借书，量查你报出“所有关于物理的书”，管理员得推着车在书架间绕半天；你说“最近五年出版的量子力学入门”，他三步就能走到对应区域。SQL里对应的是WHERE条件、索引命中、分区裁剪。但很多人写批量查询，只是简单地把WHERE IN后面的问号从十个加到一千个——这不算批量，这是把原来的问题放大十倍。

我见过最离谱的案例，是某同事把全量用户ID塞进一个IN子句，足足八万多个参数。数据库直接拒绝执行，因为解析SQL的开销比查询本身还大。正确做法是分页，每批五百个ID，循环提交。有人嫌循环慢，但实测下来，八万ID分一百六十批跑，每批零点几秒，全部跑完比单次全量查询快一个数量级。原因在于，每批查询都能独立利用索引缓存，而一次超长IN会让优化器放弃索引，走全表扫描。

另一个细节是排序。批量查询经常配合ORDER BY使用，但如果你每批都排序，最后合并时还得再排一次。更聪明的办法是：如果业务只要求“找出符合条件的前N条”，那就在每批里先LIMIT N，最后只合并每批的前N条——这样内存占用是固定的，不会因为数据量增长而失控。我有个做电商后台的朋友，他们搞促销活动时统计活跃用户，原来跑全量要十五分钟，改成每批取TOP 1000，最后归并，总耗时不到四十秒。

别忽略连接池。批量查询如果用的是同一个数据库连接，那没问题；但如果你开多线程并发提交，每个线程一个连接，就得小心连接池最大连接数。上次压测，我们开了三十个线程，每个线程循环提交，结果连接池默认上限是二十，直接抛异常。后来把连接池调到五十，同时限制每线程的批次数，才稳定下来。批量查询的瓶颈经常不在SQL本身，而在你的应用层怎么调度。

最后说个反直觉的事：有些时候，批量查询反而比单条查询慢。比如你要查的数据已经全部在缓存里，单条查询走缓存只要几毫秒，而批量查询要组装结果、检查权限、处理嵌套对象，反而多花几十倍时间。我做过一次对比，查一千个用户的基本信息，单条循环查缓存，总耗时八百毫秒；用批量查询一次性取，反而要三秒——因为每条用户信息还关联了订单、地址等子表，批量查询要额外做多次关联查询。所以啊，批量不是万能药，得先搞清楚数据在哪。

写SQL这活儿，跟做菜差不多。材料就那几样，关键看你怎么切、怎么控火候。批量查询就是那把刀，用好了，大骨头也能轻松剁开；用歪了，案板都得劈裂。下次再遇到慢查询，先别急着加索引，算算你的数据分布，拆成几批试试。说不定，你也能把四十分钟的噩梦，变成两分半的小憩。