PostgreSQL遇到too_many_columns错误，远程帮忙修复故障的那些事儿

记得那是去年夏天一个特别闷热的下午，空调的冷气似乎都难以驱散机房服务器散发出的那股热浪，我刚泡好一杯茶，准备处理一些日常工单，突然，钉钉上一个加急的告警信息弹了出来，紧接着，业务部门的开发小哥小李的电话就直接打了过来,语气火急火燎的。

“哥，不好了！我们的核心报表系统突然挂掉了，页面直接报错，啥都查不了！用户那边已经炸锅了！”小李的声音带着明显的焦虑。

我让他别慌，先告诉我错误信息是什么，他很快从日志里截了一段过来，我一看，错误日志里赫然写着：“ERROR: target lists can have at most 1664 columns”，我心里“咯噔”一下，这是个典型的PostgreSQL的“too_many_columns”错误。

我一边通过VPN连上他们的测试环境（生产环境权限管控严格，需要申请临时权限），一边让小李把出问题的SQL语句发给我，拿到SQL一看，我差点没把嘴里的茶喷出来，这是一条非常复杂的查询，使用了大量的LEFT JOIN，连接了大概有十几张表，更关键的是，在SELECT后面，他们不是老老实实地指定需要的字段，而是图省事，用了好几个“表别名.*”，用小李的话说，（来源自当时与开发人员的对话）“这样写多方便啊，不用一个个字段手敲，反正应用层会自己解析。”

我跟他解释，问题就出在这个“方便”上，PostgreSQL有个硬性限制，就是一条查询语句最终返回的结果集，包含的列数不能超过1664列，他这个写法，每个“表别名.*”都会把它对应的那个表的所有字段都展开，他连接的那十几张表，每张表都有几十甚至上百个字段，这么一叠加，总列数轻松就超过了1664这个天花板，数据库直接就“罢工”了。

小李听了恍然大悟，但又犯愁了：“啊？那怎么办？这SQL这么长，难道要我把这几百个字段名一个个手写出来吗？那得搞到猴年马月啊！”

“当然不用那么笨，”我笑着回答，“我们有更聪明的办法。”我告诉他，最根本的解决之道是重构查询逻辑，（来源自数据库优化常识） 报表真的需要一次性关联这么多表，返回这么多字段吗？是不是可以分步骤查询，或者在应用层做数据聚合？但眼下救火要紧,这个方法来不及。

我给了他一个立竿见影的解决方案：（来源自PostgreSQL官方文档及社区实践） 使用子查询或者公共表表达式（CTE）来“化整为零”，我指导他，不要把所有的JOIN都放在主查询里，而是先把部分关联和筛选逻辑封装成几个子查询，在每个子查询内部，只选择真正需要的少数几个关键字段（比如ID和求和值），然后再将这些结果列数很少的子查询进行关联，这样，最后主查询所面对的列数就大大减少了,根本不可能触碰到1664的限制。

小李按照我的思路，花了大概半小时改写了SQL，先在测试环境跑了一遍，果然，查询瞬间成功，结果也完全正确，他高兴坏了，连连道谢，赶紧把修复后的脚本部署到生产环境,系统的报警也随之解除。

这件事之后，我特意给他们团队的开发人员做了一次简单的分享。（来源自后续的内部技术分享总结） 我强调，在数据库操作中，“SELECT ”或者“表别名.”这种写法在开发阶段虽然方便，但在正式环境中，尤其是在涉及多表关联的复杂查询里，是隐患非常大的不良习惯，它不仅可能导致今天这种“too_many_columns”错误，还会带来不必要的网络传输开销和内存占用，严重影响性能，最好的实践永远是按需索取,只查询业务逻辑真正需要的那些字段。

这次远程支援让我印象很深，它不是什么高深莫测的底层故障，就是一个由于不良编程习惯触发了数据库安全阀的典型案例，但也正因为如此，它特别有教育意义，很多时候，运维的活儿不仅仅是解决那些玄之又玄的技术难题，更多是帮助兄弟们避开这些看似简单、实则坑人不浅的“陷阱”，看着小李从最初的慌乱到问题解决后的豁然开朗，那种成就感，比喝下一杯冰镇可乐还要畅快，从那以后，他们团队在写SQL时都规矩多了，类似的问题再也没出现过，这大概就是所谓的“吃一堑，长一智”吧。