MySQL 5.7 不支持物化视图，需用触发器+中间表模拟，但要求基表写入低频、聚合简单；普通视图无法更新且查询性能差；中间表字段类型、主键设计须严格对齐；每个DML操作都需对应触发器保障一致性；触发器内禁用未声明的函数和SELECT查状态，推荐ON DUPLICATE KEY UPDATE实现原子更新。
MySQL 5.7 原生不支持物化视图，但可以用触发器 + 中间表实现近实时聚合同步——前提是基表写入频率不高、聚合逻辑不复杂；否则触发器开销会拖垮性能，甚至引发死锁或复制中断。
为什么不能直接用普通视图
普通视图只是 SQL 封装，每次查询都重跑原始语句。含 GROUP BY 或多表 JOIN 的视图，在大表上查一次就可能秒变慢查询。更关键的是：UPDATE/DELETE 语句中若引用这类视图，会直接报错 ER_UPDATE_TABLE_USED——优化器无法把视图“展开”成可更新的物理结构。
物化视图的核心是固化结果为一张真实带索引的表。5.7 没这能力，必须自己建表、自己维护一致性。
中间表字段类型和主键设计必须严格对齐
中间表不是随便建的，字段类型错一点就可能隐式转换、精度丢失或索引失效：
-
COUNT(*)必须用INT或BIGINT（取决于预期行数） -
SUM(amount)推荐用DECIMAL(15,2)，别用FLOAT存金额 - 分组字段（如
product_name）必须设为PRIMARY KEY或带UNIQUE约束，否则INSERT ... ON DUPLICATE KEY UPDATE无法正确去重 - 如果分组字段组合多个（如
(customer_id, year)），主键必须覆盖全部，且顺序一致
每个 DML 操作都要配对应触发器，漏一个就脏数据
只加 AFTER INSERT 触发器远远不够。基表一旦发生 UPDATE 或 DELETE，中间表若没响应，立刻失准：
-
INSERT：累加新值（常用INSERT ... ON DUPLICATE KEY UPDATE） -
DELETE：减去旧值（注意：OLD字段在AFTER DELETE中可用，但不能查原行其他字段） -
UPDATE：必须拆成“减旧值 + 加新值”，不能只加差值（因为OLD和NEW可能跨分组） - 触发器里禁止调用未声明
READS SQL DATA的函数或存储过程，否则在binlog_format=STATEMENT下可能复制失败
触发器里慎用 SELECT 查询中间表状态
很多示例用 SELECT ... INTO @var 先读旧值再计算，看似直观，实则危险：
- 并发写入时可能读到过期快照，导致聚合值错乱（典型竞态）
- 触发器内嵌
SELECT会增加锁范围，尤其在REPEATABLE READ隔离级别下易引发间隙锁冲突 - 更稳的方式是用
INSERT ... ON DUPLICATE KEY UPDATE或REPLACE INTO，靠唯一键驱动原子更新 - 如果真要查中间表（比如做条件判断），务必加
FOR UPDATE显式加锁，并确认事务隔离级别与业务容忍度匹配
真正难的不是写几个触发器，而是保证所有路径覆盖、所有边界不漏、所有并发安全——尤其是当基表有高频 UPDATE 或涉及多字段分组时，触发器逻辑会迅速变得脆弱。建议先在小流量表上验证，再逐步推广。
