我可能已经走过了过早优化的道路，让自己迷失了方向。我在棋盘游戏的游戏树中记录了所有可能的动作。我没有希望完成树，因为它会变得如此之大（10 ^ 28）但是如果可能的话想要得到一个很好的块。由于预期查询速度慢，我将表格拆分为树的约50个分支，后缀描述了每个分支。
不幸的是，我的应用程序有很多读取，写入，更新和连接，所以在我拆分之前，事情变得很慢。从那时起，我还添加了一些非常有用的索引，可能已经解决了最初的迟缓问题。然而，随着应用程序的发展，在如此多的表与更复杂的连接之间切换变得越来越复杂。我最近听说过使用主从设置以及合并引擎来帮助处理大型表。我选择了错误的解决方案来解决我的问题，还是应该坚持下去？
答案 0 :(得分：1)
10 ^ 28行或其他任何东西，直截了当地说，不可能。计算那么多磁盘空间的成本;那应该吓到你。你需要专注于“修剪”树木。
PARTITIONing看起来很诱人，但它本身并没有提供任何性能优势（极少数例外）。同样可以手动分区为50个表。 MERGE仅仅是PARTITION的旧版本。复制可能有助于读取扩展。分片（在多台机器上分割数据）可能有所帮助，但会增加成本和复杂性 - 并且仍然无法让你达到10 ^ 28的任何东西。
如果您提供SHOW CREATE TABLE和一些查询，我们可以讨论优化，位，索引等技术。这些可能对你有帮助。
您是否使用64位BIGINT UNSIGNED来跟踪8x8主板上的某些事物？并使用布尔运算来操作它们？在某些情况下，这可以显着减少磁盘空间，所需查询的数量等。