MySQL 中的触发器与视图

Question

出于性能原因，我们正在对大量数据进行非规范化处理。基本上，通常将 JOIN 超过 10 个表的 Query 替换为没有 JOIN 的 Query，但所有必要的数据都存储/缓存在初始表中。

我是触发器的坚定拥护者，它可以帮助我保持所有数据的更新绝对透明。公司中还有其他决策者反对使用触发器（出于多种原因）并建议改为构建 VIEW，希望 VIEW 已经针对更好的数据检索进行了优化。

在 MySQL 中是这种情况吗？

Answer 1

这取决于您打算使用的 MySQL 版本。

如果您的视图只是 10 个表的连接，没有任何分组和聚合计算，那么您为什么需要反规范化？

如果您的视图涉及分组和聚合，则必须针对裸查询和带有触发器的非规范化设计测试视图性能。没有什么比用您的数据和查询进行测试更好的了。然而，正如 MySQL 性能博客文章所暗示的那样：MySQL VIEW 作为性能麻烦制造者，视图更像是一种编写紧凑查询和代码重用的方式，而不是性能改进。有时，它们甚至会对性能产生负面影响：

如果您假设 MySQL 会以与更高级的数据库系统相同的方式优化您的 VIEW，那也是非常危险的。与子查询和派生表相同，MySQL 5.0 将失败并且在许多计数中执行效率非常低。

但请注意，这是一篇相当古老的文章（2007 年），它肯定没有考虑最近在MariaDB 5.3和 5.5（可用作 MySQL 5.1 和 5.5 的替代品）中进行的优化器改进。本节与您的问题相关：

派生表和视图的优化

• 没有派生表的早期物化（例如，FROM 子句中的子查询）和物化视图（EXPLAIN 总是即时的）
• 由于派生表合并优化，可合并派生表现在像可合并视图一样处理。
• 带键优化的派生表为优化器提供了一个选项来在物化派生表上创建索引
• 可合并视图和派生表的字段现在涉及所有使用等式的优化

MariaDB 实现的另一个功能是VIRTUAL PERSISTENT列，它有助于将某些计算存储在表中，而无需使用（邪恶的）触发器。

（旁注：带有触发器的 MySQL 中的一个问题是，当与级联外键约束混合时，它们不会被级联操作MDEV-11472激活）。

MySQL 5.6还对关于视图和派生表的优化器进行了改进，但我不知道什么时候会发布稳定版本。

总而言之，我认为您应该仔细考虑将在哪个版本上实现您的数据库，并在可能的情况下测试可用版本（MySQL 5.1（和 5.5）、MariaDB 5.3（和 5.5）、MySQL 5.6（正在开发）中的各种设计选项） ）。