【 TiDB 使用环境】生产环境
【 TiDB 版本】
ORACLE数据库当时为了写入性能好把一张账户业务表做了1024个分表，现在迁移到tidb有必要把它们合并回到一张表吗？这样做好处是程序逻辑可能会简化了，但是性能会否出现问题？
做下测试呗
tidb 就是为了不再分库分表而存在的~ 可以测试下
tidb本身就是分布式的，分表没必要吧，具体还是测试搭个环境测试下。
确实如此，很多使用TiDB的也是为了不分库分表。
实践出真知
我们从RDS迁移过来的数据库里边有分库分表，直接迁移到tidb，未做合并，性能还不错
不改变原有合理设计未必不好，为了目标库改结构也是不小的成本
性能这个要自己用业务来测试，外人很难实际评估
最好是用业务代码来压测一下
全部大佬的答案都不行，哈哈。现在在可行性评估阶段，就是要调研有没有实际例子可以参考对比，是否有改造的必要，优劣势。还在做可行性的时候，你就让我把系统改造一遍压测下再决定是不是要行动，成本太大了吧。
需要根据业务情况进行判断
这不是应该做成分区表么，在oracle中。如果在tidb中，做成1个表和多个表貌似没什么区别。都是region为单位。如果以前oracle中有业务要查两个分表的内容。那现在还是作为一个表比较好。
在将Oracle数据库中的分表迁移到TiDB时，是否将1024个分表合并回一张表，取决于多个因素，包括数据规模、查询模式、写入频率、以及TiDB的性能特性。以下是对合并分表到一张表的潜在好处和可能遇到的性能问题的分析：
合并回一张表的好处：
- 简化程序逻辑：减少分表使得程序逻辑更为简洁，不再需要处理复杂的分表逻辑，比如根据某些条件将数据路由到不同的表。
- 易于管理：维护一个表比维护多个表更为容易，备份、恢复、监控等操作都更为简便。
可能遇到的性能问题：
- 写入性能：虽然TiDB是一个分布式数据库，能够处理大规模数据和高并发写入，但是将所有数据写入到一张表可能会带来写入热点，导致写入性能下降。这需要根据实际的写入模式和TiDB的集群配置来评估。
- 查询性能：对于复杂的查询，特别是涉及大量数据的查询，分表可能通过减少数据扫描的范围来提高查询性能。将所有数据合并到一张表后，如果查询没有针对TiDB的分布式特性进行优化，可能会导致查询性能下降。
- 数据分布和负载均衡：TiDB通过其分布式架构实现了数据分布和负载均衡。在分表的情况下，可以通过调整分表策略来优化数据分布和负载均衡。将所有数据合并到一张表后，需要确保TiDB的集群配置能够合理地处理数据分布和负载均衡，以避免某些节点成为热点。
建议的解决方案：
- 评估数据规模和查询模式：在决定是否合并分表之前，需要评估数据规模、查询模式以及写入频率等因素。如果数据规模较小，查询模式简单，且写入频率不高，那么合并分表可能是一个可行的方案。
- 性能测试：在合并分表之前，建议进行性能测试，包括写入性能测试和查询性能测试。通过测试可以评估合并分表对性能的影响，并根据测试结果进行相应的优化和调整。
- 考虑TiDB的分布式特性：在合并分表时，需要充分利用TiDB的分布式特性来优化数据分布和负载均衡。例如，可以通过调整TiDB的分区键策略来优化数据分布，或者使用TiDB的负载均衡功能来确保数据在各个节点之间均匀分布。
总之，在决定是否将Oracle数据库中的分表合并到TiDB的一张表中时，需要综合考虑多个因素，包括数据规模、查询模式、写入频率以及TiDB的性能特性等。通过评估这些因素并进行性能测试，可以选择最适合的解决方案。
用tidb就是为了不分表，建议合并。对于生产来说，没有实际对比数据，领导也不信服，最好实际测一下
只要硬件到位，性能一般不会有太大问题。当然，这不是开发随便写烂SQL的理由。 
需要具体测试场景，还需要业务否配合力度，毕竟需要改代码，
针对典型场景做改造测试，我们都是这样做的，不然谁能帮你评估，同样的数据量，不同场景，不同开发水平，结果都不一样，如果你都是点查，那你不用分表了
1 个赞
建议合表
迁移的有的合并了有的没合，不想改动直接分表分区平移过来满足要求即可。有的合并起来性能下降了也不得不分。
但是为了整体的简单，性能满足开发也愿意改，还是能合就合。
分区表相对普通表出bug的概率更高，越简单越稳。