MySQL插入超长文本失败主因是max_allowed_packet限制而非字段类型，需查SELECT @@max_allowed_packet、调大服务端和客户端配置，并注意utf8mb4字符集导致字节翻倍。
直接插超长文本进 CLOB 或 TEXT 字段失败，90% 不是字段类型问题，而是 SQL 语句本身越界了——Oracle 卡在字面量限制，MySQL 卡在 max_allowed_packet 或字符集膨胀。
Oracle 报 ORA-01704：字符串字面量超 4000 字符
Oracle 解析 SQL 时，对单引号包裹的字符串字面量（'...'）有硬限制：VARCHAR2 字面量最多 4000 字符，CHAR 是 2000。哪怕目标字段是 CLOB，只要你在 INSERT 或 UPDATE 里直接写超长字符串，就会触发 ORA-01704: string literal too long。
- 别用
INSERT INTO t(clob_col) VALUES ('超长文本...');—— 这是死路 - 改用 PL/SQL 块，用变量中转：
v_text CLOB := TO_CLOB('前半段') || TO_CLOB('后半段'); - 如果文本来自文件或程序，优先走 JDBC 的
setClob()或 OCI 的 LOB 接口，绕过 SQL 解析器 - 临时调试可用
DBMS_LOB.CREATETEMPORARY+DBMS_LOB.WRITEAPPEND拼接，但生产环境应避免
MySQL 插入 TEXT 大字段卡住或报错
现象是程序无响应、连接超时、或报 Packets larger than max_allowed_packet are not allowed。根本原因不是字段类型，而是客户端发过去的整条 SQL 包太大，被 MySQL 服务端直接拒收。
- 查当前限制：
SELECT @@max_allowed_packet;（单位字节，默认通常 4MB） - 临时调高（需 SUPER 权限）：
SET GLOBAL max_allowed_packet = 64*1024*1024; - 更稳妥的做法是分片插入：把大文本按 1MB 左右切块，用
INSERT ... ON DUPLICATE KEY UPDATE content = CONCAT(content, ?)累加 - 若字段含 emoji 或中文，确认表和连接都设为
utf8mb4，否则LENGTH()算出的字节数会翻倍，实际包大小远超预期
Navicat 或命令行执行批量 INSERT 失败
不是数据错，是工具或协议层吃不消。Navicat 默认把整批数据拼成一条巨长 INSERT 语句，一旦含大字段，极易触发语法解析失败或网络超时。
- 关掉 Navicat 的“使用事务”和“自动提交”，改用“每 X 行提交一次”（建议 100–500 行）
- 导出 SQL 时选“每行一条 INSERT”，别用“多值 INSERT”格式
- 命令行导入避免
mysql -e "INSERT ..."，改用mysql db_name ，并确保文件编码是 UTF-8 无 BOM - 若仍失败，先用
SHOW WARNINGS;查是否被静默截断（比如Data truncated for column 'content'）
真正麻烦的从来不是“怎么存”，而是“谁在中间拦了一道”：Oracle 拦的是 SQL 字面量，MySQL 拦的是网络包，Navicat 拦的是语句组装逻辑。定位前先看报错来源——是数据库日志里的 ERROR，还是客户端抛的异常，或是进程卡死无输出。
