连接数不断上升,IO走高最后OOM

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】
V4.0.0
【概述】tidb、tikvIO走高,连接数不断上升,最后OOM

【背景】重启过tidb,故障依旧

【现象】业务和数据库现象
select查询没有走索引
select count(1) from tb_coupon where c_org_id=‘8’ and c_customer=‘101681748’ and c_status in(‘已用’,‘转赠中’);
show index from tb_coupon
Table |Non_unique|Key_name |Seq_in_index|Column_name|Collation|Cardinality|Sub_part|Packed|Null|Index_type|Comment|Index_comment|Visible|Expression|
---------±---------±-------------------±-----------±----------±--------±----------±-------±-----±—±---------±------±------------±------±---------+
tb_coupon| 0|PRIMARY | 1|c_org_id |A | 0| | | |BTREE | | |YES |NULL |
tb_coupon| 0|PRIMARY | 2|c_couponno |A | 0| | | |BTREE | | |YES |NULL |
tb_coupon| 1|index_cust_status_dt| 1|c_customer |A | 0| | |YES |BTREE | | |YES |NULL |
tb_coupon| 1|index_cust_status_dt| 2|c_status |A | 0| | |YES |BTREE | | |YES |NULL |
tb_coupon| 1|index_cust_status_dt| 3|c_e_date |A | 0| | |YES |BTREE | | |YES |NULL |
tb_coupon| 1|idx_orgid_batchno | 1|c_org_id |A | 0| | |YES |BTREE | | |YES |NULL |
tb_coupon| 1|idx_orgid_batchno | 2|c_batch_no |A | 0| | |YES |BTREE | | |YES |NULL |
tb_coupon| 1|indx_org_mid | 1|c_org_id |A | 0| | |YES |BTREE | | |YES |NULL |
tb_coupon| 1|indx_org_mid | 2|c_mid |A | 0| | |YES |BTREE | | |YES |NULL |

Plan: tidb_decode_plan(‘nwOIMAk2XzI3CTAJMQlmdW5jczpjb3VudChDb2x1bW4jMzUpLT4NDCQyNQoxCTMwXzI4BS7wUgoyCTEzXzIxCTEJMTQuMTczNjYzMDY0NTYwODIyCXRhYmxlOnRiX2NvdXBvbiwgaW5kZXg6aWR4X29yZ2lkX2JhdGNobm8oY19vcmdfaWQsIGNfBRSwX25vKSwgcmFuZ2U6WyI4IiwiOCJdLCBrZWVwIG9yZGVyOmZhbHNlCjIJNl83AX0yuAAAMRmwIDM1CjMJMV8yMwEleDEuMzM4OTMwNDUxNjQ4NjU4CWVxKGVuam95Y3JtLnQRqHQuY19jdXN0b21lciwgIjEwMTY4MTc0OCIpLCBpbihSMACYc3RhdHVzLCAi5bey55SoIiwgIui9rOi1oOS4rSIpCjQJMTBfMjIJliYBQGtlZXAgb3JkZXI6ZmFsc2UK’)

【业务影响】

【TiDB 版本】
V4.0.0
【附件】

  1. TiUP Cluster Display 信息
    [root@crmtidb04 ~]# tiup cluster display tidb-test
    Starting component cluster: /root/.tiup/components/cluster/v1.3.2/tiup-cluster display tidb-test
    Cluster type: tidb
    Cluster name: tidb-test
    Cluster version: v4.0.0
    SSH type: builtin
    Dashboard URL: http://192.168.0.145:2379/dashboard
    ID Role Host Ports OS/Arch Sta tus Data Dir Deploy Dir

192.168.0.143:9093 alertmanager 192.168.0.143 9093/9094 linux/x86_64 Up /data/tidb/tidb-data/alertmanager-9093 /data/tidb/tidb-deploy/alertmanage r-9093
192.168.0.143:3000 grafana 192.168.0.143 3000 linux/x86_64 Up - /data/tidb/tidb-deploy/grafana-300 0
192.168.0.143:2379 pd 192.168.0.143 2379/2380 linux/x86_64 Up /data/tidb/tidb-data/pd-2379 /data/tidb/tidb-deploy/pd-2379
192.168.0.144:2379 pd 192.168.0.144 2379/2380 linux/x86_64 Up /data/tidb/tidb-data/pd-2379 /data/tidb/tidb-deploy/pd-2379
192.168.0.145:2379 pd 192.168.0.145 2379/2380 linux/x86_64 Up| L|UI /data/tidb/tidb-data/pd-2379 /data/tidb/tidb-deploy/pd-2379
192.168.0.143:9090 prometheus 192.168.0.143 9090 linux/x86_64 Up /data/tidb/tidb-data/prometheus-9090 /data/tidb/tidb-deploy/prometheus- 9090
192.168.0.143:4000 tidb 192.168.0.143 4000/10080 linux/x86_64 Up - /data/tidb/tidb-deploy/tidb-4000
192.168.0.144:4000 tidb 192.168.0.144 4000/10080 linux/x86_64 Up - /data/tidb/tidb-deploy/tidb-4000
192.168.0.145:4000 tidb 192.168.0.145 4000/10080 linux/x86_64 Up - /data/tidb/tidb-deploy/tidb-4000
192.168.0.137:20160 tikv 192.168.0.137 20160/20180 linux/x86_64 Up /data/tidb_data/tikv-20160 /data/tidb_deploy/tikv-20160
192.168.0.138:20160 tikv 192.168.0.138 20160/20180 linux/x86_64 Up /data/tidb_data/tikv-20160 /data/tidb_deploy/tikv-20160
192.168.0.140:20160 tikv 192.168.0.140 20160/20180 linux/x86_64 Up /data/tidb_data/tikv-20160 /data/tidb_deploy/tikv-20160
192.168.0.146:20160 tikv 192.168.0.146 20160/20180 linux/x86_64 Up /data/tidb_data/tikv-20160 /data/tidb_deploy/tikv-20160
Total nodes: 13
[root@crmtidb04 ~]#

  1. TiUP Cluster Edit Config 信息

  2. TiDB- Overview 监控

  • 对应模块日志(包含问题前后1小时日志)

若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

这里意思是说上面的 SQL 应该走到索引,但最终走到了全表扫描,然后导致整体集群的 IO 负载急剧增加吗?

是的,这是目前主要怀疑的方向

上面这个 SQL 正常是应该走到 (c_customer,c_status) 的组合索引吗?如果是的话,可以看下表统计信息是否准确,若不准确的话可以重新 analyze Table;如果该方法不管用的话,可以尝试绑定下执行计划,然后看下集群的 IO 负载是否有下降

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。