sql server中charindex查找失败时返回0；它从1开始计数首次出现位置，0表示未找到，是有效整数而非null，需显式判断避免substring等函数逻辑偏差。
CHARINDEX 返回的是从 1 开始的位置索引
SQL Server 的 CHARINDEX 不像某些编程语言那样从 0 开始计数，它返回的是子字符串首次出现的「字符位置」，第一个字符位置是 1，不是 0。如果没找到，返回 0，这点必须和 NULL 区分开——0 是有效返回值，代表未匹配。
常见误用是把返回值直接用于 SUBSTRING 或 STUFF 而不加判断，导致越界或空结果：
SELECT SUBSTRING(text_col, CHARINDEX('error', text_col), 10) FROM logs;
当 'error' 不存在时，CHARINDEX 返回 0，SUBSTRING(..., 0, 10) 在 SQL Server 中会返回从开头截取的 10 个字符（行为隐式修正），但逻辑已偏离预期。
- 始终用
CASE WHEN CHARINDEX(...) > 0 THEN ... ELSE ... END显式处理未命中情况 - 若需定位第 N 次出现，
CHARINDEX本身不支持，得嵌套调用或改用STRING_SPLIT+ROW_NUMBER()配合 - 区分大小写取决于数据库排序规则（collation），默认通常是大小写不敏感；如需强制区分，显式指定二进制排序规则：
CHARINDEX('Error' COLLATE Latin1_General_BIN, text_col)
查找带空格或特殊字符的子串要小心前后空白和不可见字符
日志或用户输入中常含首尾空格、制表符（CHAR(9)）、换行（CHAR(10)）、回车（CHAR(13)）。直接查 'failed' 可能找不到实际存储为 ' failed ' 或 'failed' + CHAR(13) 的记录。
实操建议：
一款AI工具，主要用于在主代理响应前，并行运行Kimi K2.5和GPT 5.3 Codex，注入双方观点以增强认知多样性，适合需要提升相关任务效率的用户。
- 用
RTRIM(LTRIM(text_col))清理后再查，或更稳妥地用REPLACE(REPLACE(REPLACE(text_col, CHAR(13), ''), CHAR(10), ''), CHAR(9), '') - 检查原始数据是否含不可见字符：
SELECT text_col, DATALENGTH(text_col), ASCII(RIGHT(text_col, 1)) FROM ... WHERE text_col LIKE '%failed%' - 避免在
WHERE子句里对字段做复杂函数处理（如CHARINDEX(..., LTRIM(RTRIM(text_col))) > 0），否则无法走索引；可考虑计算列 + 索引预处理
CHARINDEX 在 WHERE 条件中性能不如 LIKE，但更灵活
CHARINDEX('abc', col) > 0 和 col LIKE '%abc%' 功能等价，但执行计划可能不同。SQL Server 优化器通常能将两者转为相同扫描方式，但有几点关键差异：
-
LIKE支持通配符（_、%）和ESCAPE，CHARINDEX只做字面匹配 -
CHARINDEX可以配合数值运算：比如只找「第 2 个逗号之后的内容」，就得靠多次CHARINDEX定位偏移量 - 如果列上有全文索引，且查询模式复杂（如近义词、模糊匹配），
CHARINDEX无能为力，应改用CONTAINS或FREETEXT - 在大数据量表上，纯
CHARINDEX过滤仍属全表扫描，别指望它自动利用普通索引加速
跨多行文本时 CHARINDEX 依然有效，但换行符要显式包含
SQL Server 把换行视作普通字符，CHARINDEX 默认能跨行匹配。例如文本含 'Error: timeout' + CHAR(13) + CHAR(10) + 'Stack: ...'，查 'timeout' 仍能命中。
但如果想定位「某关键词在第几行」，就得先按换行符拆分——CHARINDEX 本身不提供行号信息：
SELECT
CHARINDEX('ERROR', log_text) AS pos_first,
CHARINDEX(CHAR(13)+CHAR(10), log_text, 1) AS pos_crlf_first
FROM app_logs;
注意 CHAR(13)+CHAR(10) 是 Windows 风格换行，Linux 日志可能只有 CHAR(10)；实际使用前务必确认源数据换行符类型。
真正容易被忽略的是：CHARINDEX 对 Unicode 字符（如中文、emoji）按「字符」计数，不是「字节」。一个汉字算 1 个位置，哪怕它占 2 或 4 字节——这点和 DATALENGTH 的结果不一致，混用会导致偏移错乱。
