Question

有'team_sector'表，其中包含以下字段：Id，team_id，sect_id，size，level

它包含每个“团队”实体的少量记录（以“team_id”字段引用）。每条记录代表球队体育场的部门（共8个部门）。

现在有必要实施一些搜索：

按体育场总面积（SUM（尺寸））;
最佳品质（SUM（等级）/ COUNT（*））。

我可以创建这样的查询：

SELECT TS.team_id, SUM(TS.size) as OverallSize, SUM(TS.Level)/COUNT(TS.Id) AS QualityLevel
FROM team_sector
GROUP BY team_id
ORDER BY OverallSize DESC / ORDER BY QualityLevel DESC

但我关注的是，每次执行查询时都会对每个团队进行计算。这不是太大的开销（至少现在），但我想稍后避免性能问题。

我在这里看到2个选项。

第一个是在'team'表中创建2个附加字段（例如）并存储OverallSize和QualityLevel字段。如果'扇区'表的信息被更改 - 也更新那些表（使用触发器可能会很好，因为扇区表不会经常更改）。

第二个选项是创建一个提供所需数据的视图。

第二种选择对我来说似乎要容易得多，但我没有很多关于观点工作的经验/知识。

Q1：从您的角度来看，最佳选择是什么？为什么？可能你可以建议其他选择吗？

Q2：我能否以极少进行计算的方式创建视图（至少每天一次）？如果是 - 怎么样？

问题3：为此目的使用触发器是否合理（第一选项）。

P.S。使用MySql 5.1，团队总数约为1-2千，扇区表中的总记录数 - 总计6-8千。我明白，这些数字很小，但我想在这里实施最佳实践。

Answer 1

我不会将计算字段添加到源表中。通过使用临时表将源数据与计算数据分开。您可以使用共享PK标识的一对一映射来通过减少索引等来提高性能（因此源行的PK等于计算表中行的PK）。

好处是重建数据库时，很明显，由于没有表格，计算出的数据是陈旧的。它还允许通过简单地删除临时表来清除所有计算数据的快捷方式，例如通过cron作业。以这种方式，计算的数据行还可以保持计算数据的时间戳。以这种方式，如果最大缓存时段已到期，则计算的数据可以在加载时即时重新计算，或者在服务器安静时在夜间批量重新计算。

Answer 2

几十（千）千条记录是你不应该担心的。

最佳做法是

以规范化方式存储数据并让数据库引擎处理计算
正确索引数据，立即执行索引维护
避免使用“父”记录存储汇总值
在应用程序层中执行一些结果缓存，以避免更频繁地访问数据库服务器
当你得到它们时处理性能问题

是的，每当执行视图/查询时，数据库都会计算SUM()，但我希望对于您描述的场景，结果会很快。

如果您遇到一个非常复杂的视图需要花费很长时间来计算，并且您无法找到任何进一步优化表的方法，您可以引入一个定期填充视图结果的辅助表（或通过触发器）并查询该表而不是慢速视图。

恕我直言，预计可能的性能瓶颈并在实际出现之前“关闭”它们会浪费你的时间。

MySql：使用'view'是合理的还是我会更好地对我的数据库进行非规范化？

2 个答案: