tidb多了组件之间网络通信，延时比mysql肯定会大一点点，到那时7ms过大了，我们简单查1ms以内到2ms
1 个赞
主键不应该是point_get吗，是因为联合主键吗走的range
其实我认为毫秒级别的差距，并不能说明什么，mysql单机版本读写都是走的本地io，但是tidb存算分离。从kv到db 是需要走网络流量的。tidb的优势在于数据量成规模的存算分离的分布式计算的加成。 单表的主键查询毫秒级别的差距并不能说明什么。你还需要考虑tidb分布式节点的网络消耗
是因为他这个是聚簇索引表。而且where条件是主键第一个字段，符合最左匹配。所以直接从rowid开始扫描了。执行计划没问题。
https://docs.pingcap.com/zh/tidb/stable/clustered-indexes#聚簇索引
我的观点是，在2000w行以下，mysql是有绝对优势。既不用考虑分布式的网络开销，也不用2次提交。btree索引层数也不高。在这个数量级的数据面前，分布式是没法和单机竞争的。
从尽力优化赶上这个性能差距的角度来说，也只有2次提交这里有办法优化一下。
https://docs.pingcap.com/zh/tidb/stable/system-variables#tidb_enable_1pc-从-v50-版本开始引入
https://docs.pingcap.com/zh/tidb/stable/system-variables#tidb_enable_async_commit-从-v50-版本开始引入
而这2个参数也已经是on了。所以同硬件，这个数据量下，打不过就是打不过。没有办法。你提高一些数据量，再对比一下性能可能更接近你的环境和未来的规划。
1 个赞
请问：那应该怎么设置索引？我直接用的mysql的建表语句
ms级的差异，一般情况下可以忽略，数据量不大的话，差不多数据库都是这个性能。静等大佬分析结果
在数据量小于1000W的情况下，mysql走索引是要比tidb快的。
嗯嗯，学习了
您发的这图看不到图例，方框里的看起来响应时间还可以，但是你看后边，在 IOPS/吞吐量 不是很大的情况下，响应时间已有明显上升，达到十几 ms（监控这里是平均），所以你 SQL 很可能在有抖动
TiDB 跟 Mysql 不一样，Mysql 没写入，读取可能直接读内存就读取到数据了，但是不断 TiDB 还要维护多副本一致性，这时候是有写入的，有时候读取就被这个影响了
当时，没有其他业务在运行，只有我自己的命令查询。可能在2000w数据以下，还是mysql有优势。
小数据量 MySQL 有优势这是肯定的，它是单机数据库，但是你前边提到的这个查询跑十几ms或几十ms，我认为还是你环境不稳定导致的，你看你后边执行几次，不都是2.5ms以下吗
上面有大佬回复了，执行计划没问题，如果不需要所有字段的话，考虑是不是可以只查主键那几个字段，就不用回表了
你这已经不用回表了，因为是聚簇表，查询的已经是主键的第一个列了，已经是 TableRangescan 了
哦对，是聚蔟表，我想错了，忽略忽略🐻
Mysql和几千万行没有直接关系，重点在逻辑io
磁盘性能不太好，正常要求低于1ms，这个并发上来性能衰退很严重
多次重复执行意义不大，走了缓存（copr_cache_hit_ratio=1）。
要多次带入不同的值，避免copr_cache_hit_ratio=1。
非重复执行需要35ms，重复执行还7ms多。对比mysql，差距实在是有点大。