视图中用=比较字符串查不到数据，因字段类型不一致引发隐式转换，导致索引失效或逻辑错误；应显式转换、查执行计划、验证基础表类型对齐。
视图里用 = 比较字符串，为什么查不到数据？
因为字段类型不一致时，SQL Server 或 MySQL 可能触发隐式转换，把索引字段转成字符串再比对，导致索引失效，甚至逻辑出错。比如视图定义中写 WHERE status = '1'，但 status 是 TINYINT，数据库会把整列转成字符串去匹配——不仅慢，还可能因排序规则或截断行为漏掉结果。
实操建议：
- 显式转换：统一用
CAST(status AS VARCHAR)或保持两边类型一致，如改写为status = 1 - 查执行计划：重点关注
CONVERT_IMPLICIT警告，它直接暴露隐式转换点 - 建视图前先在基础表上跑相同
WHERE条件，确认类型是否对齐
ISNULL() 和 COALESCE() 在视图里混用会出什么问题？
两者都处理 NULL，但语义和类型推导规则不同。ISNULL()（SQL Server）返回第一个参数的类型；COALESCE() 按数据类型优先级取最高类型，且要求所有参数可隐式转为目标类型。视图一旦定义，列类型就固定了，如果后续基础表字段类型变更，COALESCE(a, b) 可能突然报错“无法将 varchar 转为 int”。
实操建议：
- 在视图中优先用
ISNULL()（SQL Server）或明确 CAST：如ISNULL(price, 0.0)，避免类型漂移 - 不用
COALESCE(col, '')去补 NULL 字符串——若col是INT，这句会强制转成字符串，影响下游ORDER BY或聚合 - 检查视图列元数据：
SELECT COLUMN_NAME, DATA_TYPE FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = 'your_view'，确认每列类型符合预期
视图里 LEFT JOIN 后的 WHERE 条件误写成过滤右表字段
这是最隐蔽的 NULL 陷阱：本意是保留左表全部记录，但把右表字段放进 WHERE，比如 WHERE o.status = 'shipped'（o 是右表别名），实际效果等同于 INNER JOIN，因为 NULL 不满足任何 = 判断。
实操建议：
- 右表过滤必须移到
ON子句：LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'shipped' - 若确实需要后置过滤，用
WHERE o.status = 'shipped' OR o.status IS NULL——但注意这通常不是业务本意 - 用
EXPLAIN（MySQL）或执行计划看实际连接类型，别只信LEFT JOIN关键字
视图嵌套太深，NULL 传播变得不可控
一个视图引用另一个视图，而后者又用了 COALESCE 或计算列，多层叠加后，原始 NULL 的语义被层层覆盖或扭曲。比如底层视图用 COALESCE(phone, 'N/A')，上层视图再做 CASE WHEN phone = 'N/A' THEN ...，表面看没问题，但一旦底层改成允许空字符串，逻辑就断了。
实操建议：
- 控制嵌套层级：生产视图尽量 ≤2 层，超过就考虑物化或重构为 CTE
- 关键字段保留原始 NULL：不要在中间视图里过早填充默认值，把
COALESCE留给最终查询层 - 加注释说明 NULL 含义：比如在视图列备注里写
-- NULL = 用户未填写，'' = 用户填了空字符串
隐式转换和 NULL 处理在视图里不像在即席查询中那么容易试错——它们固化在元数据里，影响所有调用方。最麻烦的是，问题往往不出现在视图创建时，而出现在某天基础表加了新约束、或应用升级了数据库版本之后。
