感觉tidb应该在开启参数情况下,自动检测一下系统配置的合理性。
简单的时间对比不好分析原因,最好的办法还是分析执行计划。
jion效率低往往几方面:
1,一般的建议是join表不要超过3个。
2,驱动表很重要,执行计划驱动表有没有搞对。
3,join可以走索引的,关联字段加索引能有效加速。不走可能因为没建或者统计数据不对。
like如果走索引,只会走左匹配。
最好把create 语句导出来一下,才能综合评价如何优化。
选3。PD不需要对tidb server的负荷做负载均衡,所以知道tidb server的并发度没用。
这里我给tidb提一点建议,一般大公司对数据库驱动都有严格的介质管理,不是你说换驱动就换。
所以,通过换驱动来解决问题是一个方法,但是不是好的实践。
如果想生意做大,我建议还是作为bug fix来修复。
81有tiproxy
这是个好东西,以前的用负载均衡是不带会话数据共享的,也就是说如果其中一个tidb server挂了,你原来的会话转移过去其他tidb server也没用,因为session信息丢失了。tiproxy好像可以共享会话信息。
问题1:96M参数可以调整,这个是region分裂的参数。一个表的region是可以手工设置,但是如果数量不足,可能设置后还会被合并,当然也有参数可以抑制系统自动合并。
第二个问题:实测,可以多个表,而且表数据和索引数据混合存储。
第三个问题:因为生产环境往往比测试环境配置高。简单说就是tikv的数量多,为了增强并发能力,PD会自动打散表数据到多个region,另外,生产环境可能replica数量也会多一些,看你们设置。测试环境机器配置差,有的甚至是单机,当然只能减少region了。
以上这些问题都清晰了吗
原因上面的朋友已经说了,如果想在dashboard排除这些,可选择database和添加查询条件。
我没做过运维,不过老哥。你图里的磁盘性能有点差。
PCIE 3.0 x4的磁盘读3500M/S,4.0X4可以达到7000M/s。PCIE 5.0就更加快了。
tidb就是利用NVME盘的这种高IO来设计的,确实可以把mysql摁在地上摩擦的。
要是换成HDD,只能说,违背了tidb的设计初衷了。
日志感觉挺清晰了。因为端口被占用了,netstat -nltp | grep 端口
查看是哪个进程占用了端口,我没玩过docker,单机通常都是存在其他进程占用,看看没用就kill掉,不行就换端口。
公司如果经费足,肯定用企业版呀。毕竟除了什么问题有一堆高手给你兜住。
福出者福来,爱出者爱返。有机会有条件,还是得多关照一下开源企业和开源兄弟。
在日本 tidb已经是数据库排名第一的数据库。并且是连续三年排名第一。
虽然这句话无从证实,但是也给你点赞。
是不是因为dashboard走grafana的数据。show stats_meta where table_name like 'xxx’走的应该是数据库的统计数据。结果不一样,说明grafana是不是有问题?
explain analyze 查看执行计划,跟原来postgresql的执行计划对比一下,就知道问题在哪里了。很多时候dba为了省事,配置tidb不自动进行统计信息采集,也可能会带来问题。你可以看看表统计信息是否采集了。
最佳答案都选好了,我也认同。
另外提醒一下要考虑truncate时候,1,这个表是否有高频的修改和删除,可能会影响truncate的执行。2,是否存在ddl队列排队。
这个问题有点笼统了。看使用场景吧。tidb主打的是一个newSQL,性能能够根据需求扩展。
mysql好处是稳定,但是通常开始就要做好性能需求分析,选择好合适的机器,mysq估计装在power上面性能还是很强劲的,但问题是贵呀。
在目前讲求经济性,讲求x86下移的大趋势下,tidb以后应该会比mysql更有想象空间,更符合性能可以弹性拓展的大趋势。
如果是我,我估计会先升级从节点,毕竟从节点影响比主节点小很多。有什么问题都能够从主节点重新恢复。当然如果官方有指引,当我没说。