LEFT(content, 200)在视图中可能失效，主因是字段类型（如SQL Server的TEXT/ntext）、数据库版本（如MySQL 5.7不支持REGEXP_REPLACE）、多字节字符截断乱码及驱动限制，非函数本身问题。
SQL 视图里不能真正“清洗”文本，但可以安全截断、去空格、统一换行——前提是用对函数、避开类型陷阱、防乱码截断。
为什么LEFT(content, 200)在某些场景会失效
不是函数本身有问题，而是字段类型和数据库版本共同导致的隐式行为：
-
TEXT或ntext类型在 SQL Server 2008 及更早版本中，LEFT可能被驱动或查询执行器截断为 4000 字符（ODBC 默认映射限制） - MySQL 5.7 不支持
REGEXP_REPLACE，若用SUBSTRING_INDEX处理换行，遇到连续 \r\n\r\n 就容易漏掉中间空行 - PostgreSQL 的
LEFT对TEXT安全，但若字段实际是bytea或含 BOM，截取后可能显示异常字符 - 所有数据库中，直接
LEFT(content, 200)不判断长度，UTF-8 下可能在多字节字符中间切断，造成乱码（如中文“你好”被截成“你”）
跨数据库安全截断写法（带省略号+防乱码）
核心是：先判长度 → 再截 → 最后补标记。避免用 LIMIT 或 TOP，那是结果集控制，不作用于字段。
- MySQL：
CASE WHEN LENGTH(content) > 200 THEN CONCAT(LEFT(content, 197), '...') ELSE content END（LENGTH按字节计，197 是为 3 字节 UTF-8 字符留余量） - PostgreSQL：
CASE WHEN LENGTH(content) > 200 THEN LEFT(content, 197) || '...' ELSE content END（||是标准字符串拼接，比CONCAT更可靠） - SQL Server：
CASE WHEN LEN(content) > 200 THEN LEFT(content, 197) + N'...' ELSE content END（注意用LEN而非DATALENGTH，前者按字符，后者按字节）
视图里唯一靠谱的“格式化”操作
别试图在视图里做 HTML 去标签、JSON 解析或正则替换——这些要么不支持，要么性能爆炸。只做三件事，且必须用各库都稳的支持函数：
- 首尾空格：一律用
TRIM(content)，别写TRIM(' ' FROM content)（SQL Server 不认） - 换行标准化：MySQL/PostgreSQL 用
REPLACE(REPLACE(content, '\r\n', '\n'), '\r', '\n')；SQL Server 用REPLACE(REPLACE(content, CHAR(13)+CHAR(10), CHAR(10)), CHAR(13), CHAR(10)) - 空白折叠（可选）：用嵌套
REPLACE把多个连续空格/制表符转成单空格，但注意深度别超 3 层，否则可读性骤降
TEXT/CLOB 字段进视图前必须检查的两件事
否则视图建得出来，一查就报错或慢到卡死：
- 确认字段没参与
GROUP BY或ORDER BY—— MySQL 会报BLOB/TEXT column used in key specification without a key length，SQL Server 可能拒绝执行计划缓存 - 如果源表还在用
text/ntext（尤其 SQL Server 2008），先用ALTER TABLE ... ALTER COLUMN content VARCHAR(MAX)升级类型，否则任何字符串函数都可能触发隐式转换警告甚至失败
真正麻烦的从来不是怎么截，而是谁来保证原始数据进库前已经过清洗——视图只是最后一道轻量展示层，扛不住脏数据冲击。
