类型转换（尤其是隐式或函数包裹的转换）会阻断谓词下推——优化器无法将WHERE条件映射回基表索引列，导致全表扫描、ALGORITHM=TEMPTABLE降级及索引失效；应将转换移至应用层、CTE或建生成列索引。
类型转换（尤其是隐式或函数包裹的转换）会让优化器失去对原始列物理结构的感知，谓词下推基本失效——不是它不努力，是它“认不出”那个字段还对应着基表的可索引列。
CAST/CONVERT 函数直接阻断下推路径
视图定义里写了 CAST(create_time AS DATE) 或 CONVERT(VARCHAR, id)，那这个字段就不再是基表的原始列，而是一个计算结果。优化器无法把外层 WHERE create_date = '2025-06-01' 安全地映射回底层 create_time 列的索引范围。
- MySQL 8.0+ 和 PostgreSQL 支持函数索引，但前提是查询条件必须**直写基表列 + 相同函数形式**，比如
WHERE CAST(create_time AS DATE) = '2025-06-01'才可能命中INDEX idx_cast_date ON t(CAST(create_time AS DATE)) - 如果视图用了
CAST，而你外层查的是WHERE create_date = '2025-06-01'（即视图字段名），那函数索引完全无效——因为优化器看到的是视图字段，不是基表表达式 -
EXPLAIN里一旦出现Using where; Using temporary或type: ALL，基本可判定下推失败
隐式转换比显式更危险
当视图字段类型和外层 WHERE 的字面量类型不一致，数据库会自动加一层隐式转换，比如视图里 id 是 BIGINT，你写 WHERE id = '123'，MySQL 就会悄悄变成 WHERE CAST(id AS CHAR) = '123'，这等价于在索引列上套函数。
- 常见触发场景：视图字段声明为
VARCHAR，但底层是INT；或 JSON 字段用JSON_EXTRACT提取后未转类型 - PostgreSQL 对隐式转换更严格，常直接报错或拒绝走索引；MySQL 则容易静默退化为全表扫描
- 用
SHOW WARNINGS（MySQL）或EXPLAIN (VERBOSE)（PG）能捕获这类隐式转换提示
ALGORITHM=TEMPTABLE 是默认终点
只要视图定义含任何类型转换函数（CAST、TO_CHAR、DATE() 等），MySQL 大概率设 ALGORITHM=TEMPTABLE，哪怕你显式声明 ALGORITHM=MERGE，也会被忽略。
-
SHOW CREATE VIEW v_name查看结果，若含ALGORITHM=TEMPTABLE，说明结果已物化为临时表，外层WHERE只能在临时表上过滤，根本触不到基表索引 - 临时表无统计信息、无索引（除非显式定义），
EXPLAIN中会出现<derivedn></derivedn>，这就是下推彻底中断的标志 - 别指望
/*+ MERGE() */hint 强制改算法——MySQL 5.7/8.0 对含函数视图的 hint 支持极弱，基本无效
替代方案：把转换移到应用层或 CTE
想保住下推能力，就得让过滤条件直接作用于基表原始列。类型转换不是不能做，而是不能“藏在视图里”。
- 用 CTE 替代视图：先
SELECT ... FROM base_table WHERE create_time >= '2025-06-01' AND create_time ，再在 CTE 上做 <code>CAST或格式化 - 应用层处理展示逻辑：数据库只返回
create_time原值，由代码转成日期字符串，避免 SQL 层污染 - 如必须复用转换逻辑，建生成列（MySQL 5.7+/PG 12+）并为其建索引：
ALTER TABLE t ADD create_date DATE AS (DATE(create_time)) STORED，然后视图基于该生成列，而非函数调用
最易被忽略的一点：即使你确认视图没用 CAST，只要用了任何带类型语义的函数（比如 JSON_UNQUOTE(JSON_EXTRACT(...))），就可能触发隐式转换链，导致下推悄无声息地失效。检查执行计划永远比相信视图定义更可靠。
