Oracle中CLOB字段搜索必须用DBMS_LOB.INSTR()而非LIKE，因其不支持CLOB类型；SQL Server处理varchar(max)需防隐式截断；PostgreSQL中bytea与lo不可混用，且无原生分块API。
Oracle 用 DBMS_LOB.INSTR() 搜索，不能用 LIKE
直接在 CLOB 字段上写 WHERE description LIKE '%关键词%'，99% 会报 ORA-00932: 数据类型不一致。这不是语法错，是 Oracle 强制的类型限制——LIKE 不支持 CLOB 作为操作数。
DBMS_LOB.INSTR() 是唯一稳定可用的内置方案，它做的是二进制级子串匹配，绕过字符集转换和类型强制。
- 必须显式传入起始位置和第几次出现：
DBMS_LOB.INSTR(description, '测试', 1, 1) > 0 - 中文/emoji 场景下，
start_position和nth_appearance是按字节算的，不是字符数；AL32UTF8 下一个汉字占 3 字节 - 空 CLOB 会被扫描，加
AND DBMS_LOB.GETLENGTH(description) > 0避免无谓开销 - 只用于
WHERE过滤，别放在SELECT列表里调用，否则全表扫描无法提前终止
SQL Server 的 varchar(max) 替换要防隐式截断
表面看 UPDATE t SET content = REPLACE(content, '旧', '新') 能跑通，但超大值（比如 5MB 的 varchar(max)）很可能静默失败：客户端协议层 max_packet_size 默认 4MB，超出部分被丢弃，不报错也不提示。
更隐蔽的是 T-SQL 表达式拼接：@a + @b + @c 中任意中间结果超 8000 字节，就会触发隐式转换成 varchar(8000)，后面内容全丢。
- 安全做法是分块处理：先
SELECT @len = LEN(content) FROM t WHERE id = @id，再用.WRITE()分段覆盖 - 避免在存储过程中做流式模拟；
READTEXT/WRITETEXT已弃用，且不兼容其他数据库 - 如果必须全文检索，确认列已加入全文索引、
is_enabled = 1，且用CONTAINSTABLE控制回查字段，别SELECT *
PostgreSQL 的 LO 和 bytea 别混用
PostgreSQL 有两套机制：bytea 是内联二进制字段，lo（大对象）是独立 OID 实体。想存大文本又搜内容，很多人误以为 bytea 就是 LO，结果 lo_from_bytea() 返回的 OID 存进 int4 字段，读的时候就崩了——OID 必须存进 oid 类型字段。
搜索替换只能靠应用层或外部工具，纯 SQL 没有原生分块 API。想模糊查，得走 pg_trgm 扩展 + GIN 索引，但对 >10MB 的 bytea 字段建索引会卡住。
- 客户端上传用
lo_from_bytea(0, $1)，返回值必须存进oid列，不能转int4 - 读取大内容用
lo_get(oid)，但它一次性加载全部进内存，>100MB 小心 OOM -
lo_export()只能写服务器磁盘，无法直出到应用层
跨数据库统一替换逻辑根本不存在
Oracle 的 DBMS_LOB.WRITEAPPEND()、SQL Server 的 .WRITE()、PostgreSQL 的 lo_put()（已废弃）底层模型完全不同：一个是定位器+分块写，一个是偏移覆盖，一个是 OID 指针管理。硬套一套“流式处理”逻辑（比如 SqlBytes.Stream）在 Oracle 或 MySQL 上直接报错。
真正可移植的做法只有两种：要么把大文本拆成小块（如每 4KB 一行）存在普通 varchar 表里，自己拼；要么干脆把处理逻辑移到应用层，数据库只存路径或哈希。
