left函数仅在查询时截取字符串而不修改源数据，需用coalesce处理null、注意索引失效风险，各数据库语法略有差异，性能优化建议使用生成列或预存摘要。
LEFT函数在SELECT中截断字段长度
直接用 LEFT() 函数就能控制显示字符数，避免一整列全是超长文本挤占界面。它不是修改数据，只是查询时临时截取——这点很多人误以为会改库，其实完全不影响源数据。
常见错误是写成 LEFT(column, 100) 却忘了加别名，结果字段名变成 LEFT(column, 100) 这种难看的表达式；或者在 WHERE 或 ORDER BY 里滥用 LEFT() 导致索引失效。
-
LEFT()在 MySQL、SQL Server、PostgreSQL（需用LEFT()或SUBSTRING()）都支持，但 SQLite 只认SUBSTR() - MySQL 中
LEFT('hello world', 5)返回'hello'；超过原长不会报错，就返回原字符串 - 如果字段是
TEXT类型且长度极大，LEFT()不影响查询性能，但若在WHERE LEFT(col, 10) = 'abc'中使用，基本无法走索引
配合CASE WHEN处理NULL和空字符串
真实业务里，字段经常是 NULL 或一堆空格，直接 LEFT(col, 20) 会把 NULL 显示成空值，前端可能渲染异常；更糟的是，LEFT(NULL, 20) 结果还是 NULL，但有些 BI 工具会报错或卡住。
必须显式兜底，尤其是对接报表或 API 输出时。
- 用
COALESCE(col, '')把 NULL 转成空字符串再截取：LEFT(COALESCE(description, ''), 50) - 想统一补“…”后缀？得用
CASE WHEN LENGTH(col) > 50 THEN CONCAT(LEFT(col, 47), '...') ELSE col END - 注意
LENGTH()和CHAR_LENGTH()区别：中文场景优先用CHAR_LENGTH()，避免一个汉字算成多个字节
替代方案：JSON 输出时用SUBSTRING + TRIM更稳妥
如果查询结果要转 JSON 给前端，光靠 LEFT() 可能不够——比如字段含换行符、控制字符，前端渲染会错乱。这时候得组合清洗。
例如日志摘要字段带
等，直接 LEFT(log_text, 100) 可能截在换行中间，显示不整齐。
- 先
TRIM()去首尾空白：LEFT(TRIM(log_text), 100) - MySQL 8.0+ 可用
REGEXP_REPLACE()干掉换行：LEFT(REGEXP_REPLACE(log_text, '[\r\n\t]+', ' '), 100) - 旧版 MySQL 只能嵌套
REPLACE()，但三层以上就难读了，不如应用层处理
前端分页时LEFT截取反而暴露性能问题
有人在分页查询里对大字段全量 LEFT(content, 200)，看着每页只显示前200字很合理——但数据库仍要读完整字段进内存，尤其 content 是 MEDIUMTEXT，IO 和网络传输压力不小。
这不是 LEFT() 的锅，而是设计没分层：摘要应该单独存字段，或用生成列（MySQL 5.7+）预计算。
- 建表时加个虚拟列：
summary VARCHAR(200) STORED AS (LEFT(content, 200))，查它比每次计算快 - 如果不能改表，至少确认
content字段没被 SELECT * 拖累——只查需要的字段 + 截取列 - PostgreSQL 用户注意：
LEFT()对TEXT没问题，但pg_trgm扩展不加速LEFT()查询，别指望它优化 WHERE
真正麻烦的不是怎么截，而是截完要不要保留原文入口、截的长度是否该随设备响应式变化、以及有没有人把 LEFT() 当脱敏手段用——它不加密不掩码，敏感字段该脱敏还得上 REPLACE() 或应用层处理。
