在 MySQL 存储过程里替换 JSON 字段内容时，如果代码先把目标字段当成“大字段”去元数据表或 information_schema 中查找类型信息，而查询结果为空，就可能主动抛出一个业务层提示：“大字段信息不存在”。这个错误并不是 MySQL 原生的标准报错，而是应用代码或存储过程在更新 JSON 之前做字段类型校验时产生的。很多系统为了安全更新 TEXT、BLOB、JSON 等大字段，会先校验字段是否属于允许更新的大字段类型，校验逻辑一旦漏掉 json 类型，就会把 JSON 字段误判为普通字段，最终报出这条信息。

要真正解决这个问题，需要先弄清楚存储过程在更新 JSON 时经历的几个步骤：读取字段元数据、判断字段类型、拼接动态 SQL、执行更新。任何一个环节对 json 类型的处理不完整，都可能导致“大字段信息不存在”。下面从错误来源、动态 SQL 写法、修复方案和工程化建议四个角度展开。

一、先定位错误的真正来源

MySQL 5.7 开始引入原生 JSON 类型，information_schema.columns 表中 json 字段的 data_type 明确显示为 json。但很多旧系统或低代码平台在设计时，只把 text、longtext、mediumtext、blob、longblob、mediumblob 视为大字段类型，没有把 json 加入白名单。于是当存储过程执行到字段类型校验时，查询元数据表得到空结果，代码判断“字段元数据不存在”，就抛出“大字段信息不存在”。

还有一种情况出现在使用 information_schema 查询字段类型时。部分云数据库账号没有读取 information_schema.columns 的权限，或者查询时表名大小写不一致，导致查不到任何记录。存储过程拿到一个空类型值后，也会误认为该字段不是大字段。下面这段存储过程片段就是一个常见的错误示例：

-- 错误示例：只查询传统大字段类型，漏掉了 json
SELECT field_type INTO v_type
FROM sys_field_meta
WHERE table_name = 'user_profile'
  AND field_name = 'profile_json'
  AND field_type IN ('text','longtext','mediumtext','blob','longblob','mediumblob');
IF v_type IS NULL THEN
    SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '大字段信息不存在';
END IF;

在上面这段逻辑中，如果 profile_json 字段在 sys_field_meta 表中登记的类型是 json，但查询条件没有包含 json，v_type 就会是 NULL，从而触发错误。这类问题不是 MySQL 引擎的问题，而是业务层元数据管理遗漏导致的。

与此同时，也有同学把 MySQL 原生的 BLOB/TEXT 索引错误和这个提示混淆。实际上原生错误通常是“BLOB/TEXT column used in key specification without a key length”，它与“大字段信息不存在”完全是两个层面的报错。定位时应该先确认错误是在存储过程主动 SIGNAL 抛出的，还是在执行 SQL 时由 MySQL 返回的。

二、存储过程动态替换 JSON 的典型写法与隐藏问题

在存储过程中更新 JSON 内容，字段名和表名往往需要动态拼接，因为 PREPARE 语句不能直接使用变量作为标识符。常见的写法是先从元数据表获取字段类型，再拼接 UPDATE 语句，用 JSON_SET 或 JSON_REPLACE 替换指定路径的内容。下面是一段完整的动态更新存储过程示例：

DELIMITER $$
CREATE PROCEDURE sp_update_json_field(
    IN p_table VARCHAR(64),
    IN p_field VARCHAR(64),
    IN p_id BIGINT,
    IN p_path VARCHAR(128),
    IN p_value JSON
)
BEGIN
    DECLARE v_type VARCHAR(32);
    DECLARE v_sql TEXT;
    SELECT data_type INTO v_type
    FROM information_schema.columns
    WHERE table_schema = DATABASE()
      AND table_name = p_table
      AND column_name = p_field;
    IF v_type IS NULL THEN
        SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '大字段信息不存在';
    END IF;
    IF v_type NOT IN ('json','longtext','mediumtext','text','longblob','mediumblob','blob') THEN
        SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '字段不是可替换的大字段类型';
    END IF;
    SET v_sql = CONCAT('UPDATE ', p_table,
                       ' SET ', p_field, ' = JSON_SET(', p_field, ', ',
                       QUOTE(p_path), ', CAST(? AS JSON)) WHERE id = ', p_id);
    SET @sql = v_sql;
    SET @value = p_value;
    PREPARE stmt FROM @sql;
    EXECUTE stmt USING @value;
    DEALLOCATE PREPARE stmt;
END$$
DELIMITER ;

这段代码的思路本身没有问题，但它在查询 information_schema 时使用 column_name = p_field，如果传入的字段名大小写与实际表结构不一致，或者当前数据库账号没有 information_schema 的查看权限，v_type 就会是 NULL，从而报出“大字段信息不存在”。另外，如果 p_field 或 p_table 来自上游接口且没有做白名单校验，直接拼接 SQL 还会带来注入风险。

JSON_SET 函数本身不会因为字段类型是 json 而报“大字段信息不存在”。它的作用是按照 JSON 路径替换或插入值。真正的痛点在于：很多存储过程在动态更新之前，必须要判断该字段是否允许大字段替换，而判断依据往往来自一张自定义元数据表。只要这张表的数据维护不及时、类型枚举不完整，就会把 JSON 字段排除在大字段之外。

三、从元数据查询到 SQL 执行的完整修复

修复这个问题，最直接的做法是把 json 类型加入字段类型白名单。如果使用 information_schema 查询，可以将判断条件改为包含 json，同时增加大小写兼容和数据库过滤。下面是一个修正后的元数据查询示例：

SELECT data_type INTO v_type
FROM information_schema.columns
WHERE table_schema = DATABASE()
  AND table_name = p_table
  AND column_name = p_field
  AND data_type IN ('json','longtext','mediumtext','text','longblob','mediumblob','blob');
IF v_type IS NULL THEN
    SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '大字段信息不存在';
END IF;

如果系统使用的是自定义元数据表 sys_field_meta，那么需要增加一次数据订正，把现有 JSON 字段补齐到元数据表中，并将 field_type 更新为 json。订正动作可以用下面这条语句完成，前提是元数据表结构允许写入：

INSERT INTO sys_field_meta(table_name, field_name, field_type)
SELECT table_name, column_name, data_type
FROM information_schema.columns
WHERE table_schema = DATABASE()
  AND data_type = 'json'
ON DUPLICATE KEY UPDATE field_type = VALUES(field_type);

修复完元数据后，存储过程执行到类型校验时就能正确识别 json 字段。接下来还要检查动态 SQL 本身是否正确处理 JSON 路径和值。JSON_SET 的第一个参数是 JSON 文档，第二个参数是路径字符串，第三个参数是新值。如果路径来自变量，必须用 QUOTE 函数包裹，否则路径会被 MySQL 当作标识符解析，导致语法错误。值部分建议使用占位符参数化，避免直接拼接字符串造成 SQL 注入。

如果既不想维护元数据表，又不想依赖 information_schema 权限，也可以改用静态字段名更新。对于结构固定的表，不需要动态获取字段类型，直接写死 UPDATE 语句即可。例如：

UPDATE user_profile
SET profile_json = JSON_SET(profile_json, '$.contact.mobile', '13800000000')
WHERE user_id = 1001;

这种方式不涉及“大字段信息不存在”的校验，因为它跳过了元数据判断。对于需要通用替换能力的系统，还是建议保留字段类型校验，但必须保证类型白名单覆盖 json。同时，可以在存储过程中增加调试输出，把查到的 v_type 记录到日志表，方便排查元数据查询是否返回了空值。

四、工程化建议：避免大字段误判

从长期维护角度，只修补一个存储过程是不够的。字段类型映射应该作为系统级配置统一管理，而不是散落在每个存储过程或服务代码里。可以在配置中心维护一张字段类型表，把 json、longtext、text、blob 等大字段类型集中登记。存储过程执行前，通过统一函数获取类型，避免各处判断逻辑不一致。

另一个容易忽略的问题是账号权限。云数据库或生产环境常常限制应用账号读取 information_schema。如果存储过程依赖 information_schema.columns，但账号没有权限，查询会返回空结果，从而误报“大字段信息不存在”。解决方式有两种：一是为执行存储过程的账号授予 information_schema 的只读权限；二是在应用发布时把表结构同步到自定义元数据表，由应用自身维护字段类型信息。

还要注意 JSON 字段长度和 max_allowed_packet 的关系。JSON 内容可能很大，如果一次更新值超过 max_allowed_packet，MySQL 会返回包过大的错误，这不是本文讨论的“大字段信息不存在”，但同样会影响大字段更新成功率。建议在业务层对 JSON 大小做预估，必要时拆分更新或压缩存储。对于需要频繁按路径更新 JSON 的场景，也可以考虑将高频访问的 JSON 子项拆成普通字段或生成列，减少对整段 JSON 的替换操作。

最后总结一下：MySQL 存储过程替换 JSON 内容时出现“大字段信息不存在”，核心原因是字段类型校验逻辑没有把 json 当作大字段，或元数据查询因为权限、大小写、元数据表维护缺失而返回空值。修复时要先确认错误来源，再调整白名单和查询条件，最后统一字段类型管理，才能从根上避免这类误报。