问题描述
有两个表products和submissions，它们都具有大约一百万条记录并且已完全索引，我想根据条件对元素进行计数。但是，即使计算加入的基本结果也很慢。
表具有1-1关系，其中submissions具有product_id外键。请参阅以下4个查询：
select count(*)
from products P
join submissions S on S.product_id=P.id
# Takes 2 seconds
并解释该查询：
1 SIMPLE S index submissions_product_id_foreign submissions_product_id_foreign 4 NULL 776660 Using index
1 SIMPLE P eq_ref PRIMARY PRIMARY 4 ma_prod.S.product_id 1 Using index
但是，运行以下查询：
select count(*)
from products P
RIGHT join submissions S on S.product_id=P.id
需要300毫秒。解释也不同：
1 SIMPLE S index NULL submissions_product_id_foreign 4 NULL 776662 Using index
我无法全神贯注于正在发生的事情。这两个查询具有相同的结果，并且执行相同的联接，那么为什么要跳过eq_ref操作呢？此外，eq_ref在外键上应该是超快速的。
解决方法
?- bagof(X,ancestor(X,eve),Out).
Out = [muriel,aubin,jeanne,genevieve,irene,emilie,colette,joseph,michel,xxx,marcel,alain].
的MySQL文档非常密集，但有趣的是：
STRAIGHT_JOIN与JOIN相似，除了左表始终 在正确的表格前阅读。这可以用于那些（很少）情况 为此，联接优化器以次优方式处理表 订单。
对于您的查询，var PushBullet = require('pushbullet');
var pusher = new PushBullet('o.dXXXXXXXXXXXXXXXXXXXXXXXXXd'); <- Censored API Token
pusher.devices(function(error,response) {});
pusher.link('uXXXXXXXXXXXXXXXXXS','Test','https://github.com/','Recu?',function(error,response) {});
会说服优化器在左表之前读取右表，这更好。接受每个提交并使用主键查找其附带的单个产品-对比接受每个产品并查找与之相关的多个提交，甚至使用索引。后一种方法显然会遍历整个表多次。
我认为您基本上是在联接优化器中处理错误或弱点，仅此而已。有时，MySQL仍需要出色的DBA帮助才能更好地运行查询。
, RIGHT和LEFT JOINs说，其中一个表（分别为左侧或右侧）的存在是可选的。
通常，当您希望NULLs缺少数据或发现丢失的行时，使用left或right。但是你都不做。
您要查询的是提交的数量，而不是真正在乎是否有匹配的product。并且优化器意识到product毫无用处，并在设计查询执行时将其丢弃。
因此，它更快。但是可能有不同的COUNT(*)。
那么，您要它“快速”还是“正确”？