功能索引仅加速DML中的条件定位（UPDATE/DELETE的WHERE、INSERT ON DUPLICATE KEY的冲突检测），不能直接提升INSERT/UPDATE/DELETE执行速度，需结合写放大、扫描行数、事务粒度等综合优化。
MySQL 8.0.13+ 支持功能索引（Functional Key Parts），但**它不能直接优化 DML 操作本身（如 INSERT/UPDATE/DELETE 的执行速度）**，而是通过加速 WHERE、ORDER BY、JOIN 等查询条件，间接减少锁持有时间、降低扫描行数，从而缓解 DML 带来的竞争和延迟。真正想“优化 DML”，得从索引设计是否减少写放大、是否避免全表扫描更新、是否支持高效定位入手。
功能索引能用在哪些 DML 场景？
功能索引只影响 DML 中的「条件定位」部分——也就是 UPDATE 和 DELETE 的 WHERE 子句，以及 INSERT … ON DUPLICATE KEY UPDATE 的冲突检测。它对纯插入（无唯一约束检查）或无 WHERE 的 DELETE 没有加速作用。
常见可用场景：
-
UPDATE users SET status = 'archived' WHERE YEAR(created_at) = 2023 AND MONTH(created_at) = 6→ 可建(YEAR(created_at), MONTH(created_at))功能索引 -
DELETE FROM logs WHERE JSON_EXTRACT(metadata, '$.service') = 'auth'→ 可建(JSON_EXTRACT(metadata, '$.service'))功能索引（需虚拟列或 8.0.17+ 直接支持） -
INSERT INTO orders ... ON DUPLICATE KEY UPDATE total = VALUES(total)，若冲突键是LOWER(email)，可建(LOWER(email))功能唯一索引
建功能索引时最容易踩的坑
功能索引不是“函数随便套就能用”，MySQL 对表达式有严格限制：
- 表达式必须是 deterministic（确定性）：不能含
NOW()、UUID()、RAND()、用户变量@var等 - 不能引用非确定性函数，比如
CONVERT_TZ(created_at, '+00:00', @@time_zone)在会话级时区变化时会被拒绝 - JSON 函数仅部分支持：
JSON_EXTRACT()和JSON_UNQUOTE(JSON_EXTRACT())可以，但JSON_CONTAINS()不行 - 表达式结果类型必须可索引：比如
CAST(SUBSTRING(name, 1, 10) AS CHAR(10))比裸SUBSTRING(name, 1, 10)更稳妥（避免隐式转换失败）
建索引失败时典型报错：ERROR 3752 (HY000): Expression #1 of index 'idx_func' is not allowed in generated columns or functional indexes，基本就是踩了上述某条。
功能索引 vs 虚拟列 + 普通索引，怎么选？
两者在查询性能上等价，但维护成本和灵活性不同：
- 功能索引更轻量：不修改表结构，不增加列，适合临时/试探性优化
- 虚拟列 + 索引更可控：可显式定义数据类型、是否允许 NULL、是否参与分区；还能被 SELECT 直接引用，调试更直观
- 注意：虚拟列默认是
STORED才能建索引；VIRTUAL列不能建索引（8.0.13–8.0.19 限制，8.0.20+ 已支持 VIRTUAL 列索引，但仍有兼容性风险） - 如果表达式要复用多次（比如多个查询都用
DATE(created_at)），优先建虚拟列；如果只是单点优化，功能索引更快上线
示例对比：
ALTER TABLE events ADD INDEX idx_date_created ((DATE(created_at))); -- 功能索引
ALTER TABLE events ADD COLUMN created_date DATE AS (DATE(created_at)) STORED; ALTER TABLE events ADD INDEX idx_created_date (created_date); -- 虚拟列方式
DML 性能真正卡点常不在功能索引上
很多人加了功能索引后发现 UPDATE 还是慢，问题往往出在别处：
- WHERE 条件匹配了太多行 → 功能索引再快，也要逐行加锁、逐行更新；先确认
EXPLAIN FORMAT=TREE显示扫描行数是否合理 - 更新字段本身在二级索引里 → 每次 UPDATE 都触发索引树维护，尤其是大字段（
TEXT、长VARCHAR）或多个二级索引时，写放大严重 - 事务过大：批量 UPDATE 未分页，导致 undo log 膨胀、锁等待加剧；功能索引解决不了事务粒度问题
- 没有主键或主键设计不合理（如用 UUID）→ 即便有功能索引，聚簇索引插入仍随机，影响整体写吞吐
功能索引是精准手术刀，不是止痛片。它让“找得到”更快，但“改得多”“锁得久”“写得散”这些 DML 根本瓶颈，得靠分库分表、归档策略、异步化或 schema 重构来解。
