I do not explain the logic of the query，因为它并不简单。如果我详细解释 - 没有人会想要阅读和深入研究查询的本质。
有两个查询。他们做得很好。结果：相同。在手动模式下检查，用铅笔在纸上（和数据库上）。
哪个查询会减少加载服务器的负担？或者只有在真正（生产）服务器上工作后才能找到它？
操作UNION非常硬加载服务器？ What should I look for in the explanations of the querys?
1 q whith + + +
select (select count(comid) from coms join posts on pid=pid_coms where uid_posts=8888 and uid_coms=8888)
+
(select count(comid) from frends join posts on sl_frend=uid_posts join coms on pid=pid_coms
where uid_coms=8888 and m_frend=8888 and ((postacc=1 and postcomacc=2) or (postacc=2 and postcomacc=2) or (postacc=2 and postcomacc=1)))
+
(select count(comid) from frends join posts on m_frend=uid_posts join coms on pid=pid_coms
where uid_coms=8888 and sl_frend=8888 and ((postacc=1 and postcomacc=2) or (postacc=2 and postcomacc=2) or (postacc=2 and postcomacc=1)))
+
(select count(comid) from coms join posts on pid_coms=pid where uid_posts != 8888 and uid_coms=8888 and postacc=1 and postcomacc=1) CountMyComms;
EXPLAIN
+----+-------------+--------+--------+-----------------------+----------+---------+---------------------+------+----------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+--------+--------+-----------------------+----------+---------+---------------------+------+----------------+
| 1 | PRIMARY | NULL | NULL | NULL | NULL | NULL | NULL | NULL | No tables used |
| 5 | SUBQUERY | coms | ref | uid_coms,pid_coms | uid_coms | 4 | const | 7 | |
| 5 | SUBQUERY | posts | eq_ref | PRIMARY,pid,uid_posts | PRIMARY | 4 | mbs.coms.pid_coms | 1 | Using where |
| 4 | SUBQUERY | frends | ref | m_frend,sl_frend | sl_frend | 4 | const | 1 | |
| 4 | SUBQUERY | coms | ref | uid_coms,pid_coms | uid_coms | 4 | const | 7 | |
| 4 | SUBQUERY | posts | eq_ref | PRIMARY,pid,uid_posts | PRIMARY | 4 | mbs.coms.pid_coms | 1 | Using where |
| 3 | SUBQUERY | coms | ref | uid_coms,pid_coms | uid_coms | 4 | const | 7 | |
| 3 | SUBQUERY | posts | eq_ref | PRIMARY,pid,uid_posts | PRIMARY | 4 | mbs.coms.pid_coms | 1 | Using where |
| 3 | SUBQUERY | frends | ref | m_frend,sl_frend | sl_frend | 4 | mbs.posts.uid_posts | 1 | Using where |
| 2 | SUBQUERY | coms | ref | uid_coms,pid_coms | uid_coms | 4 | const | 7 | |
| 2 | SUBQUERY | posts | eq_ref | PRIMARY,pid,uid_posts | PRIMARY | 4 | mbs.coms.pid_coms | 1 | Using where |
+----+-------------+--------+--------+-----------------------+----------+---------+---------------------+------+----------------+
11 rows in set (0.00 sec)
2 q联盟
select count(comid) from (select comid from coms join posts on pid=pid_coms where uid_posts=8888 and uid_coms=8888
union
select comid from frends join posts on sl_frend=uid_posts join coms on pid=pid_coms
where uid_coms=8888 and m_frend=8888 and ((postacc=1 and postcomacc=2) or (postacc=2 and postcomacc=2) or (postacc=2 and postcomacc=1))
union
select comid from frends join posts on m_frend=uid_posts join coms on pid=pid_coms
where uid_coms=8888 and sl_frend=8888 and ((postacc=1 and postcomacc=2) or (postacc=2 and postcomacc=2) or (postacc=2 and postcomacc=1))
union
select comid from coms join posts on pid_coms=pid
where uid_posts != 8888 and uid_coms=8888 and postacc=1 and postcomacc=1) a;
EXPLAIN
+----+--------------+----------------+--------+-----------------------+----------+---------+---------------------+------+------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+--------------+----------------+--------+-----------------------+----------+---------+---------------------+------+------------------------------+
| 1 | PRIMARY | NULL | NULL | NULL | NULL | NULL | NULL | NULL | Select tables optimized away |
| 2 | DERIVED | coms | ref | uid_coms,pid_coms | uid_coms | 4 | | 7 | |
| 2 | DERIVED | posts | eq_ref | PRIMARY,pid,uid_posts | PRIMARY | 4 | mbs.coms.pid_coms | 1 | Using where |
| 3 | UNION | coms | ref | uid_coms,pid_coms | uid_coms | 4 | | 7 | |
| 3 | UNION | posts | eq_ref | PRIMARY,pid,uid_posts | PRIMARY | 4 | mbs.coms.pid_coms | 1 | Using where |
| 3 | UNION | frends | ref | m_frend,sl_frend | sl_frend | 4 | mbs.posts.uid_posts | 1 | Using where |
| 4 | UNION | frends | ref | m_frend,sl_frend | sl_frend | 4 | | 1 | |
| 4 | UNION | coms | ref | uid_coms,pid_coms | uid_coms | 4 | | 7 | |
| 4 | UNION | posts | eq_ref | PRIMARY,pid,uid_posts | PRIMARY | 4 | mbs.coms.pid_coms | 1 | Using where |
| 5 | UNION | coms | ref | uid_coms,pid_coms | uid_coms | 4 | | 7 | |
| 5 | UNION | posts | eq_ref | PRIMARY,pid,uid_posts | PRIMARY | 4 | mbs.coms.pid_coms | 1 | Using where |
| NULL | UNION RESULT | <union2,3,4,5> | ALL | NULL | NULL | NULL | NULL | NULL | |
+----+--------------+----------------+--------+-----------------------+----------+---------+---------------------+------+------------------------------+
12 rows in set (0.00 sec)
答案 0 :(得分：1)
看起来您正在寻找表格的一系列不同查询的记录总数。
第一个选择...计算每个查询的结果，然后添加它们......会更快。为什么？它的工作量较少。你的第二个选择必须纠缠一组comid值，然后计算它们。这需要时间。
如果可以，请使用COUNT(*)。这个更便宜。尽可能使用UNION ALL代替UNION; UNION删除了重复项，而UNION ALL则没有。删除重复项需要时间。
任一替代方案的性能取决于每个子查询的索引的良好选择。