有一个相当简单的查询，我必须在一个生命系统上运行，以获得计数。问题是表和数据库设计效率低下，因为它是一个改变生命系统的系统，所以此时不是一个选项。
因此，我必须找出一个运行速度快且不会使系统放慢太多的查询，因为在查询执行时系统基本上停止了，这不是我想要的生命系统要做的事情，所以我需要简化我的查询，以使其在可接受的时间内执行。
SELECT id1, count(id2) AS count FROM table GROUP BY id1 ORDER BY count
DESC;
所以这是查询，不幸的是它很简单，我没有关于如何进一步改进它的想法，也许其他人有想法......？
答案 0 :(得分：0)
申请获得足够好的＆＃34;应用程序更改的结果：
如果您可以访问应用程序而不是数据库，那么有可能：
定期运行该慢查询并捕获结果。然后使用缓存的结果。
您是否需要所有
目标是什么？找一些最常见的id1＆＃39; s？对所有人进行排名？
返回查询
COUNT(id2)检查id2是否为空;这通常是不必要的，所以COUNT(*)更好。然而，加速是微不足道的。
ORDER BY NULL如果您要选择具有最高COUNT的行，则无关紧要 - 需要在某处进行排序。将其移至应用程序并没有帮助;至少不多。
添加LIMIT 10只会有所帮助，因为减少了将数据发送回客户端的时间。
INDEX(id1)是查询的最佳索引（在更改为COUNT(*)之后）。但该操作仍需要
COUNT和GROUP BY ORDER BY 零或接近零的停机时间
您是否建立了复制？ Galera Clustering？
查看pt-online-schema-change和gh-ost。
真正的目标是什么？
我们无法按查询方式修复查询。我们可以改变什么？更好的是，最终的目标是什么 - 也许有一种方法不涉及任何看起来最像你试图加速的查询。
答案 1 :(得分：0)
现在我刚刚转储表并将其导入MySQL-Docker，在那里运行查询，花了很长时间我实际上不得不移动我的整个Docker，因为转储是如此巨大，但最后我得到了我的结果现在我知道有多少id2s与特定的id1s相关联（撇号形成复数？你可能想要仔细检查;）。） 正如已经指出的那样，查询的空间不大了。
FYI突然之间关于停止系统的关注已经消失，现在我们正在索引该表，到目前为止它花了6个小时，看不到尽头：D
无论如何，感谢大家的帮助。