这个问题听起来可能有点笼统。仍然。我们有一张桌子，上面有数亿个记录。为了制作报告，还有其他几张较小的桌子也加入了它。为所有适当的列创建索引。客户希望获得一年 的报告，最多可达100OM行。
为了保护该过程，说脚本是否死亡，或者是否与数据库的连接下降，则必须在块中提取报告，因此下一个过程会在上一个死亡的报告中获取报告。
。问题是可以通过VARCHAR/INT列对报告进行排序，该列可以包含客户端名称，帐号，不同格式的各种个人数据等，我还没有解决如何获得合理量的在这些情况下，每个块的行(例如〜50k(。
使用限制x，y对于此数量的数据将花费太长。没有存档表，没有分区，数据没有汇总到单独的表。一个表中只是大量数据。
是否有一种已建立的(魔术？(处理这种问题？
"是否有一种已建立的(魔术？(处理这种问题的方法？" - 您在问我花了很多时间完善的几件事。
"数亿个记录...报告"one_answers"报告可以用各列列对报告进行排序" - 摘要表可以更快地运行：http：//mysql.rjweb。org/doc.php/summarytables。摘要表有助于分类。
"为所有适当的列创建索引" - 对我的犬儒主义感到抱歉，但我发现该短语意味着您有一堆单柱INDEXes，但还没有了解合适的"复合''的好处"索引。http://mysql.rjweb.org/doc.php/index_cookbook_mysql和http://mysql.rjweb.org/doc.php/index1
"使用限制和偏移" - 这就是为什么它非常低效：http：//mysql.rjweb.org/doc.php/pagination。我不认为需要OFFSET解决您的问题。"记住您离开的地方"可能会帮助最初构建摘要表。
"连接到DB Drops" - 上述提示应使其足够快以避免此问题。如果不是，请提供SHOW CREATE TABLE，SELECT，以及可能的其他详细信息。
"块" - 以下是有关块的技巧，但我认为这不是解决问题的解决方案：http：//mysql.rjweb.org/doc.php/deletebig#deleting_in_in_in_chunksph e>
"一张桌子中的数亿个记录..." - 不是问题。我的技巧是针对那个尺寸的。
"没有分区" - 很好。我不必花时间说服您，分区不太可能有帮助：http：//mysql.rjweb.org/doc.php/partitionmaint
您赢得了奖项。我认为我从来没有指向我的6个博客来回答一个问题。