group_concat结果被静默截断的主因是group_concat_max_len默认仅1024字节，超长即丢且不报错；需通过show variables确认，用set session临时调大或修改my.cnf永久生效，并注意其单位为字节、受utf-8编码和max_allowed_packet限制。
查 group_concat_max_len 是否过小
这是最常被忽略的无声截断源：用 GROUP_CONCAT() 拼接多行时，结果默认最多 1024 字节，超长就直接砍掉，不报错、不警告。
执行 SHOW VARIABLES LIKE 'group_concat_max_len'; 看当前值。若为 1024 或更低，基本可以锁定问题。
临时修复：SET SESSION group_concat_max_len = 1048576;（设为 1MB）；
长期方案：在 my.cnf 中加 group_concat_max_len = 1048576 并重启 MySQL。
注意：该参数是字节长度，不是字符数；含中文时实际能拼的字符更少。
确认 max_allowed_packet 是否限制返回包
当查询返回单行数据特别大（比如一个 LONGTEXT 字段含几 MB 内容），MySQL 服务端会按 max_allowed_packet 截断整个结果包，客户端可能收到不完整数据或直接报 Lost connection to MySQL server during query。
查当前值：SHOW VARIABLES LIKE 'max_allowed_packet';
常见默认值是 4MB，但应用层（如 Python 的 PyMySQL、PHP 的 mysqli）也有自己的包大小限制，需同步检查。
调大它：SET GLOBAL max_allowed_packet = 67108864;（64MB），并确保客户端驱动也支持同等大小。
检查字段类型是否真能存下数据
TEXT 类型最大 65535 字节（约 64KB），MEDIUMTEXT 是 16MB，LONGTEXT 是 4GB。如果插入时没报错但查出来少了，很可能是写入阶段就被截断了——MySQL 在严格模式关闭时会静默截断而非报错。
验证方式：SELECT id, LENGTH(content) FROM table_name WHERE id = ?; 和原始数据比对字节数；
看表结构：DESCRIBE table_name; 确认字段类型；
升级字段：ALTER TABLE table_name MODIFY content MEDIUMTEXT;
注意：修改大表字段可能锁表，生产环境需评估窗口期。
排除客户端或驱动层的截断行为
有些客户端工具（如旧版 Navicat、某些 JDBC 驱动）默认只取前 N 字符显示，或配置了 resultSetSize 限制；Python 的 pymysql 默认不限制，但若用了 cursor.fetchmany(size) 且 size 过小，也会“看起来像截断”。
排查方法：在 MySQL 命令行客户端直接执行同一 SQL，对比输出；
检查应用代码中是否显式调用了类似 LEFT(content, 500)、SUBSTR() 或设置了 fetch size；
对 PHP，确认 mysqli_options($conn, MYSQLI_OPT_MAX_BUFFER_SIZE, ...) 未被误设；
关键点：截断发生在哪一层，得靠“绕过中间件直连 MySQL”来定位。
GROUP_CONCAT 和字段类型隐式截断，它们不会中断查询，只会悄悄丢数据。动手前先问一句：你看到的“不完整”，是在日志里、API 返回里，还是客户端界面上？位置不同，排查路径完全不同。
