update 更新变慢,where条件是主键+其他

mysql> create index idx_order_id on bot_order (order_id);
ERROR 1061 (42000): index already exist idx_order_id
mysql> create index idx_strategy_type on bot_order (strategy_type);
Query OK, 0 rows affected (3.01 sec)

mysql> set global tidb_auto_analyze_ratio=0.2;
Query OK, 0 rows affected (0.03 sec)

mysql> set global tidb_auto_analyze_start_time=‘00:00 +0800’;
Query OK, 0 rows affected (0.03 sec)

mysql> set global tidb_auto_analyze_end_time=‘06:00 +0800’;
Query OK, 0 rows affected (0.02 sec)

mysql> set global ### tidb_enable_pseudo_for_outdated_stats
->
-> ;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your TiDB version for the right syntax to use line 1 column 10 near “”
mysql> set global tidb_enable_pseudo_for_outdated_stats=off;
然后需要那几张表就更新那几张表的统计信息。这样不会向你这样大幅度变慢
analyze table xxx;

最好用 auto random

这个明显有热点, auto increment

使用到了分区,非聚族索引表,pk是联合主键,没想到热点了,看流量不是很大

我从slowlog 捞出来,看是使用到了primary key,大佬你说的在analyze tabley影响集群资源吗,看analyze时间难道是全表统计而不是采样吗

你这个是点查,和统计信息没什么关系

都point get 了,执行计划应该没问题的

看看grafana的tikv的raftmessage处理那里,看看每条消息的propose时间多少。如果时间比较长,看看rocksdb_raft\roksdb_kv哪个的压力比较大。可以参考 TiDB 写入慢流程排查系列(一)— 前言

方便的导入一下performance overview 面板,然后贴一下该段时间的性能指标,看看慢在哪里

https://docs.pingcap.com/zh/tidb/stable/performance-tuning-methods#低于-v610-的-tidb-版本如何使用-performance-overview-面板

该主题在最后一个回复创建后60天后自动关闭。不再允许新的回复。