MySQL 5.7 虚拟列不能仅在从库加索引缓解主从计算压力，因虚拟列定义属DDL需主从一致；可行方案是主库建STORED虚拟列，从库对其建索引，使计算前移至写入时。
直接说结论：MySQL 5.7 的虚拟列本身不能“在从库单独加索引”来缓解主从计算压力——因为虚拟列定义是表结构的一部分，主从必须一致；但你可以用虚拟列 + 从库索引的组合策略，把原本在查询时 CPU 密集的计算（比如 JSON_EXTRACT、DATE_FORMAT、字符串拼接）提前固化为可索引列，从而让从库承担更轻量的过滤/排序任务。
为什么不能只在从库加虚拟列索引？
MySQL 主从复制基于 binlog，而虚拟列的定义（包括 GENERATED ALWAYS AS (...) VIRTUAL）属于 DDL，会完整同步到从库。如果你在从库执行 ALTER TABLE ... ADD COLUMN ... VIRTUAL，主库不会知道，下次主库执行相同 DDL 或发生表结构变更时极易报错或导致数据不一致。所以“仅从库加虚拟列”不可行。
真正可行的是：主库定义好虚拟列 → 主从都拥有该列 → 你再在从库上对这个列建索引（只要主库没禁止从库写操作，这是允许的）。
常见错误现象：
- 在从库执行
CREATE INDEX idx_virt ON t1(virt_col)后，查询仍不走索引 —— 实际是因为virt_col是VIRTUAL类型，而 MySQL 要求索引列必须是STORED才能被二级索引真正使用（InnoDB 对VIRTUAL列建索引时，值仍需实时计算，索引效率打折扣） - 误以为加了虚拟列索引就能加速
ORDER BY JSON_EXTRACT(json_col, '$.status')—— 实际上该表达式未物化，仍无法利用索引排序
正确做法：用 STORED 虚拟列 + 从库索引
STORED 类型的虚拟列会在 INSERT/UPDATE 时计算并写入磁盘，因此它的值真实存在，可以被二级索引完整引用，也能用于 ORDER BY 和 GROUP BY 排序优化。这对从库尤其关键：它把计算压力从查询时（高并发读场景）转移到写入时（通常由主库承担，且可异步缓冲）。
实操建议：
- 主库执行：
ALTER TABLE api_log ADD COLUMN api_path VARCHAR(2048) GENERATED ALWAYS AS (REPLACE(url, '.xml', '')) STORED; - 从库执行：
CREATE INDEX idx_api_path ON api_log(api_path);（注意：主库无需同步此语句，从库独立建索引不影响复制） - 确认生效：
EXPLAIN SELECT * FROM api_log WHERE api_path = '/v1/user';应显示key: idx_api_path - 避免踩坑：不要对
STORED列再做函数包装，例如WHERE UPPER(api_path) = '...'会让索引失效
哪些表达式适合放进 STORED 虚拟列？
核心原则：表达式必须是 deterministic（确定性）的，且计算开销值得预存。MySQL 5.7 明确禁止使用 NOW()、CURRENT_USER()、子查询等非确定性内容。
推荐场景：
- 从
JSON字段提取固定路径：status TINYINT GENERATED ALWAYS AS (json_col->>'$.status') STORED - 日期截断：
log_month DATE GENERATED ALWAYS AS (DATE_SUB(created_at, INTERVAL DAYOFMONTH(created_at)-1 DAY)) STORED - 组合标识符：
tenant_user_id VARCHAR(64) GENERATED ALWAYS AS (CONCAT(tenant_id, '_', user_id)) STORED - 避免使用：
MD5(url)（太重）、UUID()（非确定性）、IFNULL(..., NOW())（含非确定函数）
从库索引不是万能的，得看查询模式
即使你建了 STORED 虚拟列和索引，以下情况依然可能绕过索引：
- 查询条件用了范围+函数混合，如：
WHERE api_path LIKE '%user%' AND status = 1（LIKE前缀模糊会失索引） - 联合查询中虚拟列出现在
ON条件但驱动表选错，优化器放弃使用索引 - 从库开启了
read_only=ON但未设super_read_only=OFF，导致CREATE INDEX被拒绝（需临时关闭read_only） -
SELECT *+ORDER BY virt_col且结果集大，仍可能触发 filesort —— 这时需要覆盖索引，比如INDEX idx_cover (api_path, created_at, id)
最易被忽略的一点：STORED 列虽然物理存储，但它的值在主库写入时就已计算完成；如果主库负载高，写入延迟变大，从库的“计算压力”其实是被转移成了主库的“写入压力”。要不要用，得看你的瓶颈到底在读还是写。
