普通索引因最左前缀原则和查询模式多变易失效；虚拟列+函数索引可将动态条件物化为固定列并建索引，提升任意组合查询性能，但需注意类型、字符集显式声明及更新开销。
为什么普通索引无法应对动态搜索条件
当搜索条件频繁变化（比如前端传参组合不定：可能只查 category_id，也可能加 status 和 price_range，甚至带 is_promotion 标志），靠预设的几个单列或固定联合索引很容易失效。最左前缀原则会让 WHERE status = 1 AND is_promotion = 1 这类跳过左侧字段的查询完全用不上 (category_id, status, is_promotion) 索引。
更麻烦的是，业务上线后新增一个搜索维度（比如加个 region_code），就得补建索引、等待重建、观察线上性能——过程不可控，还容易误伤写入性能。
虚拟列 + 函数索引是更轻量的解法
MySQL 5.7+ 支持虚拟列（VIRTUAL），配合函数索引，能把“动态组合逻辑”固化到索引结构里，而不是靠人工猜查询模式。关键不是堆索引，而是把条件判断提前物化。
例如，商品表常需按“是否新品+是否特价+是否包邮”三者任意组合筛选，可建：
ALTER TABLE products ADD COLUMN search_flags TINYINT UNSIGNED AS ( (is_new << 2) | (is_discount << 1) | is_free_shipping ) STORED;
然后直接在该列建索引：
CREATE INDEX idx_search_flags ON products(search_flags);
查询时用 WHERE search_flags & 5 = 5（即同时满足 is_new 和 is_free_shipping）就能走索引。比写一堆 OR 或 IN 更稳定，也避免了 OR 导致的索引失效问题。
- 虚拟列必须声明为
STORED才能被索引（VIRTUAL列不支持索引） - 函数表达式要确定、无副作用，不能含
NOW()、RAND()等运行时函数 - 位运算比字符串拼接更省空间、比较更快，适合布尔型组合场景
LIKE 模糊搜索也能用虚拟列加速
用户搜“iPhone”，后台实际要匹配 name、brand、model 三个字段，传统做法是 WHERE name LIKE '%iPhone%' OR brand LIKE '%iPhone%' OR model LIKE '%iPhone%' —— 全表扫描没得跑。
改用虚拟列预合并关键文本：
ALTER TABLE products
ADD COLUMN search_text TEXT AS (
CONCAT_WS(' ', name, brand, model)
) STORED;再建全文索引：
ALTER TABLE products ADD FULLTEXT(search_text);
查询就变成：
SELECT * FROM products
WHERE MATCH(search_text) AGAINST('+iPhone' IN BOOLEAN MODE);注意：FULLTEXT 索引只支持 MyISAM 和 InnoDB，且最小词长默认为 4（iPhone 没问题，但 AI 会被截断）；如需搜短词，得调 ft_min_word_len 并重建索引。
容易忽略的坑：虚拟列的类型和字符集
虚拟列的类型必须能容纳表达式结果，否则插入时静默截断或报错。比如用 CONCAT(name, ' ', description)，若 name 是 VARCHAR(50)、description 是 TEXT，结果可能超长，定义成 VARCHAR(255) 就不够用。
字符集更要一致：如果原表用 utf8mb4_0900_as_cs，虚拟列没显式指定字符集，会继承表默认，但万一某天改了表字符集，虚拟列不会自动同步，可能导致 MATCH ... AGAINST 返回空结果——这种问题在线上极难排查。
所以务必显式声明：
ADD COLUMN search_text TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs STORED
虚拟列本身不占额外磁盘（STORED 列只在写入时计算并存一次），但索引会占用空间；高频更新的字段不宜放虚拟列表达式里，否则每次更新都触发重新计算+索引维护。
