你希望活动在哪个城市举办? 杭州
你希望听到哪些技术主题分享?线上&线下皆可
如何通过Prometheus,分析数据库性能问题
目前没有使用特殊的容灾方式,就是单独的使用tidb集群的高可用+三副本方式,并且数据通过ticdc同步至离线数仓
效率低有很多因素的影响:
1、tidb集群主机配置,cpu、io、mem
2、tidb 集群中tidb、tikv个数的配置
3、tidb中压测表的主键配置,插入并发高是否热点问题
【你最想实现的 TiDB 功能需求】分区表性能提升,历史数据清理方便
【你最喜欢的 TiDB 新特性 + 理由】 索引可观测性,可以找到不用的索引,节省存储空间,同生dml效率
【你最想要周边心愿池里的哪个周边】 行李箱、 * 2023 Ti 工业风机械键盘、TiDB 67w 满电超充插头、水杯
【你考过哪些 TiDB 证书?】 PCTAv5、v6\PCTPv5
【你身边有多少位朋友在用 TiDB?】 tidb v6+
先看dashboard,是否有慢SQL引起,然后看监控通过网络,cpu、io等监控情况排查问题
先看Grafana 的over view ,在看dashboard 慢sql
重建一下对应的索引,看看是否可以解决问题, 此表是否是分区表,如果是,改为非分区表,看看如何绕过bug问题
优点:
1、给客户个性化化需求,针对不同人群(研发,生产)角色不同,资源给与不同级别,根据业务不同,给与不同级别资源限制
缺点:可能有些业务场景不需要资源限制
我认为这里并不是整个集群的问题,只是从json里面取值慢,整个集群的性能还是可以的
应该没有1m,数据之类的应该在kb之内吧,在where条件的限制下,查询结果条数2000多条数据,select列表单独整个json字段,查询整个json很快25ms,见帖子最上面的图片,但是要把json内的具体值拿出来需要1.5s
字段里面的值,配置并不确定,有的可能有这个列,有的可能没有这个列值,就是可以key values 字段,例如 {col:111 ,col2,:112 ,col3:113 } 类似这样的,都是数值类型的values
这里不是执行计划不稳定的问题,是在从json里面获取具体数据的时候慢,很稳定