如何忽略GROUP_CONCAT触发的“Row was cut by GROUP_CONCAT”错误？

首先，咱们先理清楚：明明是同版本同配置，为啥本地只截断不报错，生产却直接抛出错误？大概率是会话级别的配置差异，或者某些细节变量没对齐，咱们一步步来解决：

先排查核心差异点 #

1. 核对会话级别的sql_mode
   全局sql_mode一致不代表每个会话的配置都相同！比如你的应用程序连接数据库时，可能在生产环境额外设置了某些会话级别的sql_mode。分别在本地和生产执行这条命令：

   SELECT @@session.sql_mode;
   

   如果生产的结果里多了STRICT_ALL_TABLES或者其他严格模式相关选项，那就是它搞的鬼——严格模式会把一些警告直接升级为错误。

2. 检查sql_notes变量
   这个变量控制MySQL是否把某些警告当作错误处理。执行这条命令对比本地和生产的差异：

   SELECT @@session.sql_notes;
   

   如果生产环境的值是1（默认），而本地是0，那可以把生产的会话级sql_notes设为0试试：

   SET SESSION sql_notes = 0;
   

   要是想全局生效，就用SET GLOBAL sql_notes = 0;（需要对应权限）。

直接让错误“隐身”的办法 #

如果上面的排查没找到问题，或者你想快速解决，那可以在你的存储函数里加个错误处理逻辑，专门捕获GROUP_CONCAT的截断错误（错误码1260）：

DELIMITER //
CREATE OR REPLACE FUNCTION your_function_name(...)
RETURNS VARCHAR(...)
BEGIN
    -- 声明捕获截断错误的处理器，遇到错误就继续执行，不抛出
    DECLARE CONTINUE HANDLER FOR 1260
    BEGIN
        -- 这里不需要额外操作，因为GROUP_CONCAT已经返回截断后的字符串了
    END;

    -- 你的原有函数逻辑
    ...
END //
DELIMITER ;

这样哪怕生产环境触发了截断错误，函数也会继续执行，返回截断后的结果，和本地表现一致。

补充提醒 #

虽然你不想修改group_concat_max_len，但还是得提一句：如果生产环境的这个值比本地小很多，那截断的概率会更高。要是后续业务允许，还是建议把它调大到符合业务需求的数值，从根源减少截断的发生。

备注：内容来源于stack exchange，提问作者Elias Lopes Salmoria