MySQL错误码1111排查：无聚合函数的INSERT语句报错但手动插入正常

嘿，这个问题确实有点迷惑——明明你的INSERT语句里完全没用到聚合函数，却触发了1111错误，手动录入相同数据又能成功。我来帮你梳理几个最可能的原因和排查步骤：

最常见的元凶：表关联的触发器（Trigger） #

这是碰到这类问题时首先要排查的点。你执行INSERT操作时，tbl1.monthlydata表可能绑定了触发器，而触发器的SQL逻辑里错误使用了聚合函数（比如SUM()、COUNT()），比如：

• 在WHERE子句中直接调用聚合函数（比如WHERE SUM(amount) > 100）
• 未搭配GROUP BY就使用聚合函数做赋值或判断

排查方法： #

执行这条SQL查看该表的所有触发器：

SHOW TRIGGERS FROM tbl1 WHERE `Table` = 'monthlydata';

把每个触发器的定义拉出来仔细检查，重点看有没有违反聚合函数使用规则的逻辑——很多时候触发器的错误会“转嫁”到触发它的INSERT语句上，导致你误以为是INSERT本身的问题。

列默认值的隐性问题 #

虽然你在INSERT里指定了所有列的值，但也有可能某个列的默认值设置中用到了聚合函数（比如Amount列默认值设为SUM(other_table.col)）。这种情况下，即使你显式传了值，某些特殊场景下（比如会话级别的SQL_MODE设置）可能还是会触发默认值的计算，进而报错。

排查方法： #

查看表的完整结构，确认所有列的默认值和约束：

SHOW CREATE TABLE tbl1.monthlydata;

重点检查每个列的DEFAULT字段，看有没有使用聚合函数的情况。

会话或并发的隐性干扰 #

手动录入和程序执行INSERT可能处于不同的会话环境：

• 程序执行时可能存在未提交的事务，或者之前执行了带有GROUP BY的查询，导致会话状态异常
• 并发场景下，其他事务对关联表的聚合操作可能和当前INSERT产生冲突

排查方法： #

1. 在和手动录入相同的客户端会话中执行你的INSERT语句，看是否报错——如果不报错，说明问题出在程序端的会话配置或前置SQL上
2. 执行ROLLBACK;清空当前会话的未提交事务后，再尝试执行INSERT

客户端工具的隐性差异 #

有些程序客户端会自动为SQL添加额外的逻辑（比如自动补全、预编译参数的特殊处理），导致实际执行的SQL和你写的不一致。可以尝试把程序中执行的SQL完整打印出来，和手动录入的SQL做对比，看是否有隐性差异。

内容的提问来源于stack exchange，提问作者Eliseo Di Folco