TiDB不适合小SQL的快速访问，这句话怎么理解？

在201.1课程学习中，提到TiDB不适合小SQL的快速访问，具体原因是分布式数据库存在网络传输肯定会影响到一定的性能。

这个可否理解为，数据量和并发数不是很高的情况下，MySQL比TiDB性能要好；只有数据量和并发上去了，使用TiDB才能获得更好的结果？

另外相对于其他分布式数据库，TiDB是否是最有优势的选择？

数据量和并发数不是很高的情况下，MySQL比TiDB性能要好；只有数据量和并发上去了，使用TiDB才能获得更好的结果

----我觉得这样理解没有问题，小数据量和小并发，MySQL单机搞定，不需要像分布式数据库一样多节点，依靠高性能网络加速。

考虑到还有个因素：KV存储，本来就对读不友好。

因为分布式相比于单击数据库的优势在于当数据量大了之后的自动扩容，下推计算提高计算能力等等，而纯粹小数据量的高并发场景，单机数据库是会更强的，

因为是分布式的，所以小sql的快速访问肯定不如单机性能。

杀鸡用牛刀这样去理解

官方说5000W以下行数tidb性能不如mysql

201课程中这句话，缺乏背景环境的说明，假如说，有个系统，日增2000万订单，要求保留三年数据，并且日订单量还会随着系统推广快速增加，这样的系统，mysql如何应对？我用tidb搭建底层数据库，在这样的系统点查个数据，相对来说也挺快，比单机mysql快。

实际情况差别并不是很大, 还是要看业务 ,所有数据库选型,都离不开底层业务, 根据业务进行数据库选型,数据规划, 才能充分发挥各数据库优势

TiDB 不适合小 SQL 的快速访问，个人在实际生产应用的方面如下：
1.线上业务存在百万级别、千万级别、亿级别数据
根据纯性能验证来看，百万级别、千万级别，TiDB 的验证结果与 MySQL 的确实会存在一定差距，但差距平均值10~50ms左右，业务上实际使用几乎可以忽略这点差异，不影响正常使用。
但若单纯从部署成本考虑，百万级别数据库可能使用 MySQL 成本更低，管理层面不一定会批准这样的资源消耗。
2.从业务上讲，数据一旦上升到千万级别，并在日增的情况下，使用 MySQL 就不得不考虑分库分表等操作，实际上对于开发和运维的要求就上升了，这一层面来看，其实就是要考虑分库分表的维护成本和 TiDB 的上手学习成本？
个人认为，在 TiDB 目前的社区活跃度来看，TiDB 的学习成本和部署成本反而更低。

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。