测试环境3* tidb和3tikv在同一台服务器上 单台服务器40core 256G内存 磁盘为sata
在测试 insert效率时 从tpc-h的测试库里的part表复制1000万行数据耗时4分钟
已设置batch_size 为10000
pre_split_regions = 4
insert期间利用iostat 观察磁盘负载 每秒仅为110MB左右
请教一下如何提高insert 效率呢？
在oracle环境下试了一下单节点的同配置机器1000万行需要1分钟左右
请教一下如何提高insert 效率呢？
在oracle环境下试了一下单节点的同配置机器1000万行需要1分钟左右
2 个赞
最近看到有与MySQL比性能的，您这是跟Oracle比，我好像没有看到官方的对比数据，不知道官方对这个是个什么概念，个人觉得这样的比较不太有意义
6 个赞
我的意思是这个集群环境比单台的oracle还慢的话是不是配置哪里有问题！
2 个赞
就是因为是集群和实现方式不同，所以对比单节点的Oracle和MySQL才有可能性能上有差异，我看到的TiDB的资料是在强调同时支持OLTP和OLAP，而且又是分布式的系统，扩展性比Oracle和MySQL好，好像并没有看到官宣的在一般的查询和插入上性能比传统的RDBMS高出多少，不知道您那有相关的官方资料没？
3 个赞
Ti的文档里面有insert的测试结果https://docs.pingcap.com/zh/tidb/stable/benchmark-sysbench-v2#标准-insert-测试
我理解是这个测试是在三台节点上每个节点开了128个线程来进行的测试
在我们的场景中有大量的原来create table as的语句需要用tidb来实现所以对
insert 性能非常的关心
单独的insert 比不过mysql oracle, 使用pre_split_regions = 4有前提：1、 设置shard_row_id_bits 2\、开启tidb_scatter_region变量，才能打散。如果表内有自增列主键的话可以改成auto_random主键 。如果数据一直递增或递减插入的话那么永远只使用1个tikv， 影响性能
2 个赞
请教一下增加tikv的数量的话对insert 性能有多大的提升
1 个赞
看你写入的方式和表结构
在不改变业务逻辑的情况下只能是 insert into select形式 目标表无索引
增加tikv的前提是能打散region,且让写入流量能均衡到这些tikv, 就是我前面说的那些，我这测过20个tikv 普通ssd盘 8个tidb arm平台的，6亿数据分了80个文件用load data方式 ，8分多钟加载完的，也是无索引表
1 个赞
我也觉得TiDB集群在某些场景并不一定比单实例的RDBMS性能好，对比性能时还是要看有没有使用到TiDB的有利于性能的相关特性
3 个赞
我记得是不建议批量insert的，建议合并成一个大insert语句。
10条insert语句，每条插入一条记录。 和 1条insert语句，插入十条记录。速度是差异非常大。
rocksdb 对写的友好性，讲道理要比传统库高些。
表结构贴出来、看看是不是热点问题、如果有热点问题是有这个可能的。本身计算、存储、调度分离的架构、写入还老往一个节点写、一个节点抗压不说还比传统多了好几次网络开销。
高并发写要避免写热点。
这个比较意义不大，insert 过程中是否到了瓶颈呢
应该是单条插入友好性好一点吧，多条批量插入，实践过程中确实性能很差。现在都是把多条insert合并成一个insert去执行
多条insert合并成一个同样适用于其他数据库啊
2 个赞
我刚才试了一下增加了1倍的tikv节点对insert into 语句没有任何性能提升。
我的问题是 从库里已经存在的一张大表里面通过insert into 。。。。。select 。。。。。的方式进行数据插入目前的效率是1000万行耗时200秒左右 表结构就是tcpH测试中的part表 取消了主键 增加了shard_row_id_bits和pre_split_regions参数 在会话级设置了 tidb_batch_insert=1 tide_dml_batch_size=10000