所以我有一个看起来像这样的查询:

SELECT col1, col2, col3 ...
FROM action_6_members m
LEFT JOIN action_6_5pts f ON f.member_id = m.id
LEFT JOIN action_6_10pts t ON t.member_id = m.id
LEFT JOIN action_6_weekly w ON w.member_id = m.id
WHERE `draw_id` = '1' ORDER BY m.id DESC LIMIT 0, 20;

现在这是在进行大规模连接(350 万 * 4 万 * 2 万)

所以我的想法是:

执行SELECT * FROM action_6_members WHEREdraw_id= '1' ORDER BY id DESC LIMIT 0, 20;

然后循环使用 php 构建 $in = "IN(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20)";

然后运行
select * from action_6_5pts where member_id in $in
select * from action_6_10pts where member_id in $in
select * from action_6_weekly where member_id in $in

然后使用 php 将它们全部混在一起，

这意味着，尽管我使用了四个不同的查询，但我只从每个查询中选择了 20 行，而不是对所有行进行连接。

我会注意到显着的绩效奖金吗？

这是应用程序的总体概述

它收到一个代码，

代码可以是 5pt、10pt 或每周代码，

所有三种代码类型都在单独的表中。 三张表都有code，和member_id

member_id 链接到 action_6_members 表中的 id。

当代码被认领时，数据被填入 action_6_members 表中。

然后，该成员的 ID 将填入已声明代码的表中。

上面的查询选择了前二十个成员。

那么我的问题是。

我可以做些什么来改善这一点？

因为目前一切都在查询完成之前超时。

action_6_members

CREATE TABLE `action_6_members` (
  `id` int(11) NOT NULL auto_increment,
  `draw_id` int(11) NOT NULL,
  `mobile` varchar(255) NOT NULL,
  `fly_buys` varchar(255) NOT NULL,
  `signup_date` datetime NOT NULL,
  `club` int(11) NOT NULL default '0' COMMENT '1 = yes, 2 = no',
  PRIMARY KEY  (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=1337 DEFAULT CHARSET=latin1

action_6_ 5 和 10pts

CREATE TABLE `action_6_5pts` (
  `code` varchar(255) NOT NULL,
  `member_id` int(11) NOT NULL,
  PRIMARY KEY  (`code`),
  KEY `member_id` (`member_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

action_6_weekly

CREATE TABLE `action_6_weekly` (
  `id` int(11) NOT NULL auto_increment,
  `code` varchar(255) NOT NULL,
  `member_id` int(11) NOT NULL,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `id` (`id`),
  KEY `member_id` (`member_id`)
) ENGINE=MyISAM AUTO_INCREMENT=3250001 DEFAULT CHARSET=latin1

id select_type table type possible_keys key       key_len ref  rows   Extra  
1  SIMPLE      m     ALL  \N            \N        \N      \N   1390   Using temporary; Using filesort  
1  SIMPLE      f     ALL  member_id     \N      \N      \N   36000  
1  SIMPLE      t     ALL  member_id     \N      \N      \N   18000  Using where  
1  SIMPLE      w     ref  member_id     member_id 4    m.id 525820 Using where  

刚刚通过: DB 7.26、4.60、2.45最新加载数据

1.0 是正常的最大负载...以上任何内容都意味着它必须“爆发”并调用其他进程来处理。即 7.26 表示负载是 Blade 服务器最大负载的 7 倍，不得不请其他人帮忙

所以目前这个查询不仅仅是一个怪物，它把怪物当零食吃...

最佳答案

作为一般规则，如果您的 SQL 查询可以完全模拟您想要执行的操作，那么它可能比将其拆分成用 PHP(或任何其他语言)粘在一起的部分更快，在一定范围内界限。

这些界限是:

1. 对于本案例，MySQL中一定没有隐藏着奇怪的病态行为。
2. 您必须在所有必要的列上有合理的索引。
3. 没有(或可能)您只能在 PHP 中合理检测/处理您希望中途中止查询的情况。
4. 您的结果集不是病态的巨大(例如，它适合内存并且不超过 my.cnf 中的 max_allowed_pa​​cket 的大小)。

现在，这并没有解决您的 SQL(或建议的 PHP 替代实现)是否对您正在做的事情最佳，但只有在提供有关您的应用程序的更多信息后才能解决这个问题确实和你真正想要达到的终点。可能很好，也可能不好。

快速浏览一下您对表结构的更新，我没有想到可能会导致大型性能问题，但是:

• 除非确定需要，否则不要使用 MyISAM。 InnoDB 是您的好 helper ，尤其是当表具有相当大的写入流量时。 MyISAM 的全表锁真的可以咬你。拥有参照完整性的外键也很好。
• action_6_weekly 将 id 作为 PRIMARY KEY，并且在... 上有一个 UNIQUE KEY编号。这是多余的。 PRIMARY KEY 实际上是 UNIQUE KEY 的超集，您不需要创建单独的 UNIQUE KEY。
• EXPLAIN 对您的查询的输出会很有趣。

关于php - 将一个查询分成四个以避免大量连接？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3437371/