MySQL 优化 1-to-* 关系答案

【问题标题】：MySQL Optimization for 1-to-* RelationshipsMySQL 优化 1-to-* 关系
【发布时间】：2014-01-25 05:36:00
【问题描述】：

好的，我一直在尝试解决这个问题，但无法得出结论。我很想从你们那里得到一些结果、进行更多测试的提示或阅读更多资源。

情况很简单。有一个主要的图片表。可能是cat_pictures。有一个二级表cat_pictures_comments。一些聪明的开发者确保cat_pictures有一个自动递增的主键ID_PICTURE，并且cmets也以ID_PICTURE的索引存储。

我们的应用程序有一个页面想要显示所有图片以及每张图片的所有评论。

我们

A：如果应用程序是 PHP 怎么办？

B：如果cat_pictures 有猫基因组的条目 ID、图片文件路径和另外 20,285 个字段怎么办？ cat_pictures 还与每只猫的主人的精神科医生进行了 INNER JOIN 教育（一对一的关系）。（基本上，与我们的小型 cmets 表相比，附加到主表的数据要多得多。）

谢谢大家。

【问题讨论】：

问题不清楚。答案是加入。考虑为 1-1 数据提供附件表，但前提是它可以证明存在显着的性能优势。如有疑问，请进行测试。
对不起。这就是我要说的，我不确定如何衡量使用 PHP 获取每张图片 cmet 或使用查询获取它的好处。我觉得 PHP 可能会更好，因为存储和返回重复的 cat_pictures 数据的内存可能远远超过附加到图片的每个评论的小尺寸。
虽然可能，但在实践中，这种假设极不可能。通常，到 DB 的“往返”次数越少越好 - “1”是最佳选择。
为了使这个问题有用，有什么提示可以正确地对“断言”进行基准测试？我们应该看到时间和/或内存得到改善吗？还要考虑 PHP 中的缓存和优化以及 MySQL 中的缓存和内存...还考虑到超动态租户系统
制作几百万行（和索引）表非常简单，然后看看你得到了什么。除此之外，其他人可以这么说，因为基准测试和优化并不是我真正的地盘。

【解决方案1】：

我认为你的问题是，你是否加入了 cmets，然后有一个看起来像

的查询

选项 1

select (all pic columns), (all comment columns) from pics inner join comments;

对比。选项 2

Select * from pics; then loop and select * from comments were pictureId = @currentId;

对比。选项 3

Select * from pics order by picId; select * from comments order by picId;

在选项 1 中，您为该图片发布的每条评论都复制了图片表的每一列。如果每张图片有很多 cmets 并且图片表很宽，那么最好从数据库中提取两个单独的数据集。

在选项 2 中，如果有很多图片，您会在数据库中进行过多的往返。

基于缺乏完整的需求，我会推荐选项3。获取图片表结果和cmets作为两个单独的数据集，然后在你的php页面中：遍历每张图片并显示图片信息，然后嵌套循环得到当前图片的 cmets 来自已从 SQL Server 提取的本地 cmets 数据集。

【讨论】：

我看不出偏爱 3 而不是 1 的逻辑。我认为您很难设计出一个 3 优于 1 的场景，但很高兴被证明是错误的。
@Strawberry，如果“主”表中返回的数据过多，我觉得 3 可能优于 1...如果其中的数据量创建一个大足够的数据开销。不？因为对于每条评论，该数据在输出中都会重复
其他 RDBMS 可能更好。尽管如此，MySQL 还是喜欢（正确索引的）数据。它非常擅长处理它。它将击败 PHP。
选项 3 仍然允许 MySQL 进行处理。它只是让 MySQL 在更规范化的数据集中返回数据，因为图片父表有这么多列。有人提到图片表可能有超过 20,000 列，所以如果每张图片有 10 个 cmets 超过 11 张图片，那么在选项 1 与选项 3 中返回的额外/重复数据点超过 200 万个。添加更多图片、每张图片的 cmets 和并发用户，以及选项 1 中重复数据的开销超过了两个单独（但仍然很快）查询的成本。