SQL视图中用SUBSTRING和CHARINDEX截取字符串必须动态计算位置，因字段长度与分隔符位置不固定；需用NULLIF和CASE WHEN防CHARINDEX返回0导致SUBSTRING报错，并注意空格、NULL处理及索引失效问题。
SQL视图里用SUBSTRING和CHARINDEX截取字符串，核心是位置必须动态算出来
直接写死起始位置或长度在视图里基本不可行——字段内容长度不一、分隔符位置浮动，硬编码会批量出错。必须靠CHARINDEX先定位分隔符（比如逗号、@、下划线），再把结果喂给SUBSTRING。SQL Server 视图中不支持变量，所以所有计算得塞进单条表达式里，且要防CHARINDEX找不到分隔符时返回 0 导致SUBSTRING参数非法。
CHARINDEX返回 0 时SUBSTRING会报错，必须兜底
比如想从email字段截取@前用户名：SUBSTRING(email, 1, CHARINDEX('@', email) - 1)。如果某条记录email不含@，CHARINDEX返回 0，整个表达式变成SUBSTRING(email, 1, -1)，SQL Server 直接抛错“Invalid length parameter passed to the LEFT or SUBSTRING function”。
- 用
CASE WHEN CHARINDEX('@', email) > 0 THEN ... ELSE ... END包裹整个截取逻辑 - 更省事的是用
NULLIF(CHARINDEX('@', email), 0)把 0 转成 NULL，再配合ISNULL或COALESCE设默认值 - 别依赖
TRY_SUBSTRING——SQL Server 2022 才有，老版本视图里不能用
视图中避免SUBSTRING在WHERE子句里滥用，否则索引失效
如果在视图定义里写WHERE SUBSTRING(name, 1, 3) = 'abc'，哪怕name字段上有索引，这个条件也无法走索引查找，强制全表扫描。这不是语法问题，是执行计划层面的硬伤。
- 前缀匹配优先用
name LIKE 'abc%'，它能用上索引 - 真要按中间位置过滤（比如“第5位是X”），接受性能代价，但得在视图文档里标清楚
- 视图本身不建议带
WHERE——它该是数据源抽象，过滤逻辑留给上层查询
跨数据库移植时CHARINDEX不通用，视图没法直接复用
CHARINDEX是 SQL Server 特有函数，MySQL 用LOCATE，PostgreSQL 用POSITION，Oracle 用INSTR。同一个视图脚本扔到不同库会直接报错。
- 如果项目锁死 SQL Server，放心用
CHARINDEX+SUBSTRING - 如果需要兼容多库，视图里别做复杂截取，改用应用层处理，或拆成数据库特定的物化视图
-
SUBSTRING_INDEX（MySQL）或SPLIT_PART（PostgreSQL）虽更简洁，但完全不跨库，比CHARINDEX系列还难迁移
最常被忽略的其实是空格和 NULL：字段两端有空格时CHARINDEX可能找不准，而SUBSTRING遇到 NULL 输入直接返回 NULL，不会报错但结果不可控——写视图时得先RTRIM(LTRIM())再截取，NULL 值用ISNULL兜住，这两步漏掉一个，下游查半天都看不出哪来的空值。
