直接select *会触发全lob加载，应显式指定非lob字段、按需查询或截取预览，jdbc须用getclob()而非getstring()，where中模糊搜索应建全文索引而非依赖dbms_lob.instr()。
直接 SELECT * 会触发全LOB加载，别这么干
查一个带 CLOB 的表，写 SELECT * 或 SELECT clob_col，Oracle/MySQL 都会把整个大文本内容拉到客户端内存——哪怕你只想要前 10 行 ID 和标题。InnoDB 还可能因此读取大量溢出页，拖慢整条 SQL。
实操建议：
- 永远显式列出非 LOB 字段：
SELECT id, title, created_at FROM articles - 需要内容时再按需单查：
SELECT content FROM articles WHERE id = 123 - 若必须预览，用
DBMS_LOB.SUBSTR(clob_col, 200, 1)（Oracle）或SUBSTRING(content, 1, 200)（MySQL）截短，避免隐式转字符串失败 - ORM 框架（如 MyBatis、Hibernate）务必关闭自动映射 LOB 字段，改用延迟加载或自定义
TypeHandler
Java JDBC 读 CLOB：getClob() 是底线，getString() 是陷阱
ResultSet.getString("content") 在 Oracle 中极大概率返回 null 或截断（尤其超 4000 字节），不是数据丢了，是驱动主动放弃了——它默认按 VARCHAR2 语义处理，不走 LOB 协议。
实操建议：
- 强制用
rs.getClob("content")，再判空：if (clob != null) { clob.getSubString(1, (int) clob.length()) } - 超过 2GB 或怕 OOM？换流式读：
clob.getCharacterStream()+BufferedReader分行处理 - JDBC 4.0+ 必须调
clob.free()，否则连接池里 LOB 句柄堆积，后续查询可能卡住或报 ORA-01652 - Spring
JdbcTemplate默认不支持 CLOB 映射，得写RowMapper手动调getClob
WHERE 条件里搜 CLOB：dbms_lob.instr() 不是万能，CONTAINS() 才是正解
写 WHERE dbms_lob.instr(content, '错误') > 0 能跑通，但性能差、不支持中文分词、无法利用索引——它本质是逐行扫描 + 内存比对，空 CLOB 还会拖慢全表。
实操建议：
- 只用于简单存在性判断，且加守卫条件：
AND dbms_lob.getlength(content) > 0和AND ROWNUM = 1 - 要模糊匹配、近义词、权重排序？必须上全文索引：
CONTAINS(content, 'ORA-01461 WITH FUZZY') > 0 - 建
CTXSYS.CONTEXT索引后，记得授权：GRANT CTXAPP TO your_user，并手动同步：ctx_ddl.sync_index('idx_content') - 停用词如“的”“and”默认被过滤，业务强依赖就得自定义 stoplist 并绑定
MySQL TEXT 字段加索引：前缀长度不是拍脑袋定的
MySQL 不允许对 TEXT 建完整索引，只能前缀索引，但 INDEX(content(100)) 对日志类字段基本无效——前 100 字节全是时间戳和 IP，关键词在后面。
实操建议：
- 先统计真实分布：
SELECT MAX(CHAR_LENGTH(content)), PERCENT_RANK() OVER (ORDER BY CHAR_LENGTH(content)) FROM logs，取 P95 × 0.7 作为参考值 - 固定开头的内容（如 JSON、Markdown），前缀可很短：
INDEX(content(15))足够加速WHERE content LIKE '{"status":"%' - BLOB 类型别建前缀索引——二进制无字符顺序，
SUBSTRING()开销大，不如抽特征存进VARCHAR(255)单独索引 - 单行超 8KB 时，InnoDB 自动外存 TEXT，随机 IO 暴增，考虑压缩后存
MEDIUMTEXT或迁出数据库
真正难的不是语法，是得时刻问自己：这个 CLOB 我真需要现在加载吗？它到底该被当“数据”还是“附件”？很多性能问题，源头只是没想清楚这一句。
