【问题标题】:which one is better for performance? cross join or a new table?哪一个对性能更好?交叉连接还是新表?
【发布时间】:2011-07-23 08:42:15
【问题描述】:

我正在构建一个人脸匹配网络应用程序。

注意:我刚刚发现人们不会将这种类型的应用称为人脸匹配应用。

这是一个基本的工作流程。

  1. 用户上传照片
  2. 管理员批准/拒绝照片
  3. 当用户访问该页面时,会从数据库中随机选择两张照片。
  4. 用户有两个选项
    1. 选择其中一张照片
    2. 跳到另一场比赛

只有一个条件。用户看不到重复的匹配。如果用户已经玩过 1 vs 2,那么用户就不会再看到 2 vs 1。

假设我有以下 4 张照片

桌面照片

ID 1 2 3 4

有 6 种可能的匹配项。那些是

1对2 1对3 1对4 2 对 3 2 对 4 3对4

为了进行这些匹配,我使用以下交叉连接查询。

select p1.id, p2.id from photos as p1 cross join photos as p2 where p1.id < p2.id

它可以正常工作。我担心的是,随着匹配数量的增加,它会变慢。

我只用 2000 张照片就得到了 1999000 场比赛。这是一个巨大的数字。

所以我想到了一个解决方案,并想出了一个新表来存储所有可能的匹配项。这些行是在管理员批准照片时创建的。

表格匹配

id1 id2 1 2 1 3 1 4 等等

最后,我的问题是

我应该继续使用交叉联接还是应该创建一个新表“匹配”?

哪个更好?

任何其他更好的解决方案将不胜感激!

【问题讨论】:

    标签: mysql performance join


    【解决方案1】:

    我认为在这种情况下,您最好存储所有匹配项。如您所见,匹配数与行数成二次方。根据您的用例,似乎最好保留一个包含每个用户所有看到的对的表,并在您查询该用户时排除它们。与整个组合空间相比,这可能非常稀疏。除非您需要在管理员批准时存储所有组合的数据,否则没有理由在那时生成它们。

    【讨论】:

    • //感谢您的回复。我担心的是......在哪里有很多并发连接可能会很慢......假设是 50000。我的 MYSQL 可以处理这个交叉连接查询吗?
    猜你喜欢
    • 1970-01-01
    • 2011-10-17
    • 2011-07-20
    • 1970-01-01
    • 2019-04-08
    • 1970-01-01
    • 1970-01-01
    • 2014-10-05
    • 1970-01-01
    相关资源
    最近更新 更多