视图中调用函数会导致索引失效，因函数作用于索引列破坏B+树有序性，使优化器回退全表扫描；应改用计算列+索引或重写条件将函数移至常量侧。
视图里用函数，索引基本就废了——不是视图本身的问题，而是底层查询执行时函数作用在索引列上，破坏了B+树的有序性。
为什么视图中调用函数会让索引失效
视图本质是封装好的 SELECT 语句，MySQL 在执行时会把视图定义展开（类似宏替换），再优化执行计划。如果视图定义里写了 WHERE DATE(create_time) = '2026-01-01' 或 ORDER BY UPPER(name)，那实际执行的 SQL 就等价于在基表字段上直接用函数，触发索引失效。
- 函数作用于索引列 → 优化器无法利用索引定位数据 → 回退为全表扫描
- 即使视图字段被单独建了索引，MySQL 也不支持对视图字段建物理索引（除非是物化视图，但 MySQL 原生不支持）
-
EXPLAIN看到type: ALL或key: NULL，基本能确认是这个原因
用计算列 + 索引替代视图中的函数逻辑
把函数逻辑“下沉”到表结构层，让索引能真正覆盖它。
- 添加生成列（Generated Column）：比如原视图有
YEAR(create_time)，就在表里加create_year INT AS (YEAR(create_time)) STORED - 为该列建索引：
CREATE INDEX idx_create_year ON t_user(create_year) - 改写视图，不再调用函数，而是直接查
create_year = 2026 - 注意：
STORED类型才支持建索引，VIRTUAL不行
避免在视图 WHERE / ORDER BY 中对索引列做运算
这是最常见也最容易修复的坑。函数别写在列上，挪到常量侧。
- ❌ 视图定义含：
WHERE DATE(create_time) = '2026-08-04' - ✅ 改成：
WHERE create_time >= '2026-08-04 00:00:00' AND create_time - ❌
ORDER BY LOWER(name)→ 即使name有索引，也会失效 - ✅ 改用
ORDER BY name，并在应用层统一转小写；或建函数索引（MySQL 8.0.13+ 支持）：CREATE INDEX idx_name_lower ON t_user((LOWER(name)))
函数索引只在 MySQL 8.0.13+ 可用，且有局限
如果你用的是较新版本，函数索引是解法之一，但它不是万能的。
- 仅支持
STORED生成列或直接在索引定义里写表达式（如INDEX((LOWER(name)))） - 不能用于所有函数：只支持确定性函数（比如
LOWER()、SUBSTR()），不支持NOW()、RAND()等 - 索引本身会占用空间，且写入时要多维护一份计算值，对高并发写入表需权衡
- 旧版本（如 5.7）完全不支持，只能靠生成列 + 普通索引兜底
真正难处理的是那些必须前后模糊、必须运行时计算、又没法预置的场景——这时候视图只是表象，问题根子在查询模式本身。要么重构数据存储方式（比如倒序存 name 以支持后缀匹配），要么接受走全表扫描，再考虑用 Elasticsearch 这类外部引擎分担压力。
