一、"列必须出现在GROUP BY子句"错误 #

说白了就是PostgreSQL严格遵循SQL标准：当你用GROUP BY对数据分组时，SELECT里的每一列要么是GROUP BY里明确列出来的分组键，要么得用聚合函数（比如SUM()、MAX()、AVG()）包起来——数据库得明确知道怎么处理未分组的列，总不能随便给你返回某一行的值吧？

举个典型的错误例子：

SELECT user_id, username, COUNT(order_id) AS order_count
FROM orders
GROUP BY user_id;

这里username既不在GROUP BY里，也没被聚合函数包裹，数据库直接懵了，就会抛出那个报错。

有两种靠谱的解决方式：

• 方式1：把非聚合列加到GROUP BY里
  如果username和user_id是一一对应的（比如user_id是用户表的主键），直接把username加到GROUP BY就行：

  SELECT user_id, username, COUNT(order_id) AS order_count
  FROM orders
  GROUP BY user_id, username;
  

• 方式2：用聚合函数包裹非分组列
  如果同一分组下有多个不同的username（这种情况大多是数据设计有问题，但真遇到了也能处理），可以用MAX()、MIN()这类函数指定取哪个值：

  SELECT user_id, MAX(username) AS username, COUNT(order_id) AS order_count
  FROM orders
  GROUP BY user_id;
  

二、PostgreSQL SQL脚本执行报错的通用解决思路 #

脚本执行报错的原因五花八门，我整理了几种最常碰到的场景和解决办法：

1. 语法错误 #

报错一般会显示ERROR: syntax error at or near "XXX"，按这几步排查：

• 盯着报错位置附近的代码看：是不是漏了分号？引号没配对？关键字拼错了（比如把VARCHAR写成VARCHARR）
• 注意大小写坑：如果表名/列名用双引号包了，会区分大小写，比如"User"和user是两个完全不同的表；没包双引号的话，PostgreSQL会自动转成小写
• 拆成单句测试：把脚本里的SQL拆成一句一句在psql里跑，很快就能定位到哪行出问题

2. 权限不够 #

报错会提示ERROR: permission denied for table XXX或者ERROR: must be superuser to do this：

• 先确认执行脚本的用户有没有对应权限：比如建表要CREATE权限，插数据要INSERT权限
• 如果是需要超级用户才能干的事（比如装扩展），切换到postgres用户执行：

  sudo -u postgres psql -d your_db -f your_script.sql
  

3. 依赖没跟上 #

比如报错说ERROR: relation "XXX" does not exist：

• 检查脚本里的创建顺序：别先引用某个表，再去创建它，顺序搞反肯定报错
• 如果依赖了扩展（比如uuid-ossp），先确保扩展已经装了：

  CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
  

4. 事务冲突/锁等待 #

报错可能是ERROR: deadlock detected或者ERROR: could not obtain lock on relation "XXX"：

• 看看脚本里的事务逻辑：别让事务长时间占着锁，尽量把长操作拆短
• 如果是多个脚本同时跑，别让它们改同一份数据
• 实在不行，用SELECT pg_locks;看看当前的锁情况，把阻塞的进程杀掉（或者重启数据库，这是下下策）

5. 数据类型不匹配 #

报错会说ERROR: column "XXX" is of type integer but expression is of type text：

• 检查插入/更新的值类型和列定义对不对：比如把字符串塞到整数列里，或者日期格式写错了
• 必要时用类型转换：比如CAST('2024-01-01' AS DATE)或者更简洁的'2024-01-01'::DATE

内容的提问来源于stack exchange，提问作者Andrus