我可能过早地走上了过度优化的道路并迷失了方向。我正在记录棋盘游戏的游戏树中所有可能的 Action 。我对完成这棵树的希望不大，因为它会变得如此之大(10^28)，但如果可能的话，我希望获得一个很好的 block 。考虑到查询速度会很慢，我将表分成大约 50 个树分支，并用后缀描述每个分支。
不幸的是，我的应用程序有大量的读取、写入、更新和连接，因此在我将它们分开之前，速度很快就变慢了。从那时起，我还添加了一些非常有用的索引，这些索引可能已经解决了最初的缓慢问题。然而，随着应用程序的发展，在如此多具有更复杂连接的表之间切换变得越来越复杂。我最近听说使用主从设置以及合并引擎来帮助处理大型表。我是否为问题选择了错误的解决方案，还是应该坚持下去？
最佳答案
10^28 行或其他任何东西，坦率地说，不可能。计算那么多磁盘空间的成本；那应该会吓到你。您需要专注于“修剪”您的树木。
PARTITIONing 看起来很诱人，但它本身并没有提供任何性能优势(除了极少数异常(exception))。手动分区为 50 个表也是如此。 MERGE 只是PARTITION 的一个旧变体。复制可能有助于读取扩展。分片(将数据分割到多台机器上)可能会有所帮助，但会增加成本和复杂性，而且仍然无法达到 10^28。
如果您提供SHOW CREATE TABLE和一些查询，我们可以讨论优化、位、索引等技术。这些可能会对您有所帮助。
您是否使用 64 位 BIGINT UNSIGNED 来跟踪 8x8 板上的一些内容？并使用 bool 算术来操作它们？在某些情况下，这可以显着减少磁盘空间、所需的查询数量等。
关于mysql - 大的mysql表应该被分割，使用合并引擎，主/从还是其他什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/37911814/