不能直接用 IS NULL 或 = '' 判断大字段是否为空，因为会触发全表扫描并读取整个大字段内容，导致性能急剧下降；应改用 CHAR_LENGTH()（MySQL）或 octet_length()（PostgreSQL）配合生成列与索引优化。
为什么不能直接用 IS NULL 或 = '' 判断大字段是否为空
很多开发者一上来就写 WHERE content IS NULL OR content = ''，结果在百万级 TEXT 表上慢得离谱——因为 MySQL/PostgreSQL 会为每一行实际读取并比较整个大字段内容，哪怕只查“是不是空”。尤其当字段平均长度几 KB 以上、且未建索引时，全表扫描 + 大字段 I/O 直接拖垮查询。
MySQL 中推荐用 CHAR_LENGTH() 配合函数索引
对 TEXT 字段，CHAR_LENGTH(content) = 0 比 content = '' 更安全（兼容换行、零字节等边界），且 MySQL 能在部分版本（5.7+）对表达式做优化。但关键是要避免每次计算：
- 如果字段极少为空，加一个生成列 + 索引更高效：
ALTER TABLE articles ADD COLUMN content_is_empty TINYINT GENERATED ALWAYS AS (CASE WHEN CHAR_LENGTH(content) = 0 THEN 1 ELSE 0 END) STORED;
CREATE INDEX idx_content_empty ON articles(content_is_empty); - 不要用
LENGTH()替代CHAR_LENGTH()：二进制长度 ≠ 字符长度，多字节字符（如中文）会导致误判 - MyISAM 引擎下该优化无效，必须用 InnoDB
PostgreSQL 中优先用 octet_length() + 表达式索引
PostgreSQL 对大对象（TEXT 或 BYTEA）不支持函数索引直接建在 length() 上（因 volatile 属性），但 octet_length() 是 stable 的，可安全建索引：
- 建索引：
CREATE INDEX CONCURRENTLY idx_posts_body_empty ON posts ((octet_length(body) = 0));
- 查询写法：
WHERE octet_length(body) = 0或WHERE (octet_length(body) = 0) IS TRUE - 注意：用
body = ''在 PG 中虽语法正确，但无法走索引；IS NULL只管 NULL，不管空字符串
BLOB 字段要区分存储方式和校验逻辑
真正存二进制数据（如图片、PDF）时，'' 和 NULL 含义不同，且多数数据库不支持对 BLOB 建函数索引。此时必须靠应用层约束或冗余字段：
- MySQL：用
IS NULL查 NULL 很快，但空BLOB（即长度为 0 的二进制串）只能靠LENGTH(blob_col) = 0，且必须配合生成列索引 - PostgreSQL：
BYTEA用octet_length() = 0，但别尝试md5(blob_col)这类重计算——它会强制加载整个 blob - 最稳的方案：业务写入时统一约定，空 BLOB 存为
NULL，而非 0-length 二进制串，这样只需查IS NULL
真正卡住性能的从来不是判断逻辑本身，而是数据库是否被迫加载大字段全文。只要绕过实际读取，哪怕多加一列、多一次写入开销，查询速度也能从秒级降到毫秒级。别省那点磁盘空间，空值标记该冗余就冗余。
