数据量满足多少的情况下TiDB的收益和支出性价比最高,感谢大家的建议!
这个没有数据可以直接说个量吧，通用的决策依据是：mysql扛不住了，没办法了，就用tidb。如果mysql用着很爽，那就没必要tidb
1 个赞
个人觉得要看业务的量级吧，mysql如果达到瓶颈无法解决，可以去尝试上TiDB
我们是3T以上
领导说上就上
数据量固然很重要，但也要看数据的组成，应用等的具体情况。
单点数据量过大，且不想分库分表，分析事务过多。
tidb 基本200g就应该用tidb了
改善型的方案，当你的场景使用 mysql 很痛苦，运维压力很大的时候，就需要考虑了
当然，如果业务场景就很明确了很多性能相关的指标，可以对比 Mysql 和 tidb 做一些poc 来参考最终的收益和成本
根据 并发 ，硬件、特性需求角度考虑
一般看2个指标，1. 单表记录行数，业界的参考值，如果TP类系统 MySQL 数据库 单表 2000万，要么需要分库，要么建议使用其他数据库，如 TiDB。
2. 数据量，一般参考值 1T - 2T。到了这个规模使用 TiDB 收益非常大。
目前 TiDB 7.1 推出的资源管控（Resource Control）可以将多个小库部署在一起，这种情况便于运维的同时，做了资源管控，还是的部分数据库具备高可用和高可扩展性能力。按这个思路，其实就不需要看 记录数 和 数据量了。
1 个赞
我觉得如果mysql是需要分库分表了就可以考虑使用TIDB了
分库分表就是垃圾中的垃圾，谁用谁傻逼，你的mysql扛不住得分库分表了，就赶紧用tidb得了，折腾分库分表只能把你折腾成傻逼
勇于接受新事物但是也不能太喜新厌旧啊 
，没有tidb之前，分库分表解决了不少问题，有不少大型业务还不太信任tidb，依然在用分库分表。分库分表这个东西虽说有不少的局限性，也是立下了汗马功劳的。事务不行，但是数据放在mysql，有很多老运维用着踏实。
个人理解分几块：
- 总数据量超过单机上限，要么选择分库分表方案，要么选择分布式方案
- 热数据量超过单机内存上限，比如随机读写，当涉及大量 IO 操作时单机性能会急速下降
- 需求实时性较高的 HTAP ，可自行搜下相关内容
如果场景有联机业务和分析业务结合话，可以考虑使用tidb，
tikv提供高效的point get主键查询，tiflash提供大数据量复杂的分析查询
有了高版本的资源管控，企业内部小系统就往上堆呗，感觉挺合适的
OLTP场景单表在2000万行以上。
结合资源管控特性多业务共用一个集群，实现多租户隔离，现在已经覆盖小数据规模的领域了。除非追求极致的稳定性，不然小数据规模场景也建议放到TiDB集群
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。