应开启严格sql模式并检查字段定义，而非依赖substring()截断；mysql需启用strict_trans_tables，postgresql需处理空值和越界，优先修正表结构与配置。

MySQL插入时字符串被静默截断怎么办

MySQL默认在严格模式关闭时，会把超长字符串截掉再插入，不报错也不提醒——这是最危险的“成功”。关键不是怎么截，而是怎么让它暴露问题或安全处理。

用 SUBSTRING() 是一种兜底手段，但得清楚它只解决“数据进得去”，不解决“数据对不对”。

• 先确认当前SQL模式：SELECT @@sql_mode;，如果没包含 STRICT_TRANS_TABLES 或 STRICT_ALL_TABLES，就处于危险截断模式
• SUBSTRING(str, 1, N) 要配合字段定义长度用，比如 VARCHAR(20) 就取 SUBSTRING(col, 1, 20)，别硬写死数字
• 注意字符集影响：UTF8MB4下，一个汉字占4字节，但 SUBSTRING() 按字符数截，不是字节数，这点和 LEFT() 行为一致

PostgreSQL里SUBSTRING截字符串要防空值和越界

PostgreSQL的 SUBSTRING() 对空值、负起始位置、超长长度更敏感，不加判断容易在INSERT中直接报错中断。

它不像MySQL那样“宽容”，所以不能无脑套用。

• 遇到NULL字段必须先用 COALESCE() 或 NULLIF() 处理，例如：SUBSTRING(COALESCE(name, ''), 1, 50)
• 起始位置小于1会被当作1处理，但长度为0或负数会返回空字符串，不是报错——这点容易误判结果
• 如果源字段可能短于目标长度（比如想截100但实际只有10），SUBSTRING(str, 1, 100) 安全，不会出错，但没必要，可直接用原值

INSERT SELECT中用SUBSTRING要小心隐式类型转换

当从一张表查数据插入另一张表，且中间用 SUBSTRING() 截取时，MySQL/PostgreSQL都可能因目标列类型触发二次隐式转换，导致意外截断或报错。

比如源是TEXT，目标是VARCHAR(255)，你用 SUBSTRING(text_col, 1, 500)，数据库仍会按目标列长度再切一次。

• 显式CAST更可靠：CAST(SUBSTRING(text_col, 1, 255) AS VARCHAR(255))
• 避免在 INSERT ... VALUES 中嵌套多层 SUBSTRING()，可读性差，也难调试
• 如果源数据来自用户输入或日志，建议在应用层提前截断并记录警告，比在SQL里补救更可控

真正该优先检查的不是SUBSTRING，而是字段定义和SQL模式

花时间调 SUBSTRING() 参数，不如花两分钟看一眼表结构和数据库配置。多数截断问题根子不在函数，而在设计或部署偏差。

• 执行 SHOW CREATE TABLE your_table; 确认字段长度是否真够用，别靠“应该够”猜测
• 上线前必须检查 sql_mode（MySQL）或 check_function_bodies + 类型约束（PostgreSQL），否则测试环境不报错，生产一模一样SQL就失败
• SUBSTRING() 是手术刀，不是创可贴；它能帮你绕过单次插入失败，但掩盖不了字段容量规划缺失这个事实