logo标签列表

MySQL性能：视图 vs. 函数 vs. 存储过程

mysqlsql
4
我有一张表格，其中包含每小时收集的一些统计数据。现在我想快速地获得每天/每周/每月/每年/总体的统计数据。从性能角度来看，最好的方法是什么？创建视图？函数？存储过程？还是普通表格，在更新数据时同时写入（我想避免后者）？我的当前想法是创建一个 view_day，它汇总小时数，然后创建 view_week 和 view_month 和 view_year，它们从 view_day 汇总数据，并且创建 view_total 从 view_year 汇总。这个方案好还是不好？
5个回答
3
您基本上有两个系统：一个收集数据，一个报告这些数据。
针对您经常更新的交易表运行报告可能会导致读锁定，从而阻止写入完成速度，因此可能会降低性能。
通常强烈建议运行周期性的“收集”任务，从您（可能高度规范化的）交易表中收集信息，并将该数据放在非规范化的报告表中形成“数据仓库”。 然后，您可以将报告引擎/工具指向非规范化的“数据仓库”，而不会影响实时交易数据库的查询。
此收集任务应该只运行与您的报告需要“准确”的频率相同。 如果一天一次就足够了，那太好了。 如果您需要每小时或更频繁地执行此操作，请继续进行，但是要监控写入任务的性能影响。
请记住，如果交易系统的性能很重要（通常确实如此），则避免以任何代价针对它运行报告。
1

是的，拥有存储已聚合数据的表是一个好的实践。

而视图、存储过程和函数只会在大表上执行查询，这并不高效。

1
唯一真正快速和可扩展的解决方案就是如您所说的“普通表格，在更新数据时必须同时写入”，并使用适当的索引。您可以使用触发器自动更新此类表格。
0

我们有一个类似的问题，我们使用主/从关系。我们在主服务器上进行事务数据（包括读和写操作，因为在我们的情况下，某些读操作需要超快速，并且不能等待事务复制），而从服务器则快速地复制数据，然后我们运行每个非事务查询，包括报告。

我强烈建议这种方法，因为如果您的数据足够细粒度以在报告层/应用程序中使用，则可以将其作为快速而简单的数据仓库实施。

0
我的观点是，复杂的计算应该只在数据更改时发生一次，而不是每次查询都进行。创建一个聚合数据，并通过触发器（如果不接受日志）或通过运行一次每天或每小时或任何可接受的延迟时间的作业来填充它。如果选择触发器路线，请进行测试，测试和测试。确保它可以处理多行插入/更新/删除以及更常见的单个插入/更新/删除。确保它尽可能快速，并且没有任何错误。触发器将为每个数据操作添加一些处理，您必须确保它添加的最小可能位，并且永远不会发生任何错误，从而防止用户插入/更新/删除数据。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接