索引引起的错误

【TiDB 使用环境】生产环境
【TiDB 版本】8.5.2
【部署方式】本地24个TIKV节点
【遇到的问题:问题现象及影响】
tidb_server 节点错误日志:[2025/06/10 15:49:14.062 +08:00] [ERROR] [distsql.go:1567] [“table reader fetch next chunk failed”] [conn=516137088] [session_alias=] [error=“context canceled”]
[2025/06/10 15:49:19.371 +08:00] [ERROR] [distsql.go:1567] [“table reader fetch next chunk failed”] [conn=516137546] [session_alias=] [error=“context canceled”]
[2025/06/10 15:49:19.371 +08:00] [ERROR] [distsql.go:1567] [“table reader fetch next chunk failed”] [conn=516137546] [session_alias=] [error=“context canceled”]
[2025/06/10 15:49:19.540 +08:00] [ERROR] [distsql.go:1567] [“table reader fetch next chunk failed”] [conn=516137456] [session_alias=] [error=“context canceled”]
[2025/06/10 15:49:25.249 +08:00] [ERROR] [distsql.go:1567] [“table reader fetch next chunk failed”] [conn=516137076] [session_alias=] [error=“context canceled”]
[2025/06/10 15:49:32.167 +08:00] [ERROR] [distsql.go:1567] [“table reader fetch next chunk failed”] [conn=516137270] [session_alias=] [error=“context canceled”]
[2025/06/10 15:49:33.082 +08:00] [ERROR] [distsql.go:1567] [“table reader fetch next chunk failed”] [conn=516137436] [session_alias=] [error=“context canceled”]
[2025/06/10 15:49:33.082 +08:00] [ERROR] [distsql.go:1567] [“table reader fetch next chunk failed”] [conn=516137436] [session_alias=] [error=“context canceled”]
[2025/06/10 15:50:38.617 +08:00] [ERROR] [distsql.go:1567] [“table reader fetch next chunk failed”] [conn=516137554] [session_alias=] [error=“context canceled”]
[2025/06/10 15:54:43.124 +08:00] [ERROR] [distsql.go:1567] [“table reader fetch next chunk failed”] [conn=516137210] [session_alias=] [error=“context canceled”]
[2025/06/10 15:54:43.124 +08:00] [ERROR] [distsql.go:1567] [“table reader fetch next chunk failed”] [conn=516137210] [session_alias=] [error=“context canceled”]
[2025/06/10 15:54:43.124 +08:00] [ERROR] [distsql.go:1567] [“table reader fetch next chunk failed”] [conn=516137210] [session_alias=] [error=“context canceled”]
[2025/06/10 15:54:43.290 +08:00] [ERROR] [distsql.go:1567] [“table reader fetch next chunk failed”] [conn=516137032] [session_alias=] [error=“context canceled”]
[2025/06/10 15:59:46.824 +08:00] [ERROR] [distsql.go:1567] [“table reader fetch next chunk failed”] [conn=516137414] [session_alias=] [error=“context canceled”]
[2025/06/10 15:59:46.824 +08:00] [ERROR] [distsql.go:1567] [“table reader fetch next chunk failed”] [conn=516137414] [session_alias=] [error=“context canceled”]
[2025/06/10 15:59:47.069 +08:00] [ERROR] [distsql.go:1567] [“table reader fetch next chunk failed”] [conn=516137266] [session_alias=] [error=“context canceled”]
[2025/06/10 15:59:47.069 +08:00] [ERROR] [distsql.go:1567] [“table reader fetch next chunk failed”] [conn=516137266] [session_alias=] [error=“context canceled”
现象:程序端查询能正常出结果,只是每次查询tidb_server 节点都会出现一次错误
原因是:表的一个索引引起的,把问题索引删除重建后,现象消失
表结构:-- crawler_platform.journal_article definition

CREATE TABLE journal_article (
id bigint NOT NULL AUTO_INCREMENT,
task_name varchar(100) DEFAULT NULL,
task_tag varchar(50) DEFAULT NULL,
rawid varchar(500) NOT NULL DEFAULT ‘’,
article_info_json json DEFAULT NULL,
sub_db_id varchar(10) NOT NULL,
state int NOT NULL DEFAULT ‘0’ COMMENT ‘-1 状态为删除的数据’,
failcount int NOT NULL DEFAULT ‘0’,
ref_stat int NOT NULL DEFAULT ‘0’,
ref_failcount int NOT NULL DEFAULT ‘0’,
cite_stat int NOT NULL DEFAULT ‘0’,
cite_failcount int NOT NULL DEFAULT ‘0’,
oversea int NOT NULL DEFAULT ‘0’,
oversea_failcount int NOT NULL DEFAULT ‘0’,
t1 int NOT NULL DEFAULT ‘0’,
t1_failcount int NOT NULL DEFAULT ‘0’,
re_down int NOT NULL DEFAULT ‘1’ COMMENT ‘1为第一次下载,2为10天后的下载,3为30天后的下载,4为90天后的下载’,
is_true int NOT NULL DEFAULT ‘0’,
is_true_failcount int NOT NULL DEFAULT ‘0’,
create_time timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
update_time timestamp DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
err_msg text DEFAULT NULL,
other_dicts text DEFAULT NULL,
null_dicts text DEFAULT NULL,
page varchar(255) NOT NULL DEFAULT ‘0’ COMMENT ‘占位,不会用于实际请求中’,
PRIMARY KEY (id) /*T![clustered_index] NONCLUSTERED */,
UNIQUE KEY m_rawid (task_name,task_tag,rawid),
KEY is_true_dx (is_true,is_true_failcount),
KEY state_dx (state,failcount),
KEY update_dx (update_time),
KEY tag_isture_dx (task_name,task_tag,is_true,is_true_failcount),
KEY idx_tname_ttag_istrue_ctime (task_name,task_tag,is_true,is_true_failcount,create_time),
KEY journal_article_create_time_IDX (create_time)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin AUTO_INCREMENT=8404287708;
表数据总计大小100GB
问题索引:journal_article_create_time_IDX
执行SQL:SELECT * FROM journal_article
where task_name = ‘cnkijournal’ and task_tag=‘cnkiarticle’ and is_true_failcount<5 and is_true in (0,-1) ORDER BY create_time desc limit 100
其它问题 :问题出现前执行 这个SQL,索引不走idx_tname_ttag_istrue_ctime ,而是走journal_article_create_time_IDX

1 个赞

Hello v8.5.2 还没有正式发版,等发版后在测试看看

不是都能下载了吗?

你在哪里下载的

此报错的核心是 查询执行过程中上下文被取消 ,需优先区分是客户端主动中断还是服务端强制终止。若为后者,需从 慢查询优化、资源监控、网络排查 三个维度切入,逐步定位并解决问题。

1. 确认是否为客户端主动中断

  • 操作
    • 检查客户端连接日志,确认是否有主动断开连接的记录。
    • 若为应用程序调用,排查代码中是否有查询取消逻辑(如设置了超时回调)。
  • 解决:若非预期中断,优化客户端逻辑,避免误取消查询;若为正常终止,无需处理。

2. 排查查询超时问题

  • 操作
    • 查看 TiDB 配置文件,确认 max_execution_time 设置是否合理(可临时调大测试,如设为 600 秒)。
    • 分析慢查询日志(tidb_slow_query.log),定位超时的 SQL 语句。
    • 使用 EXPLAIN ANALYZE 分析该 SQL 的执行计划,优化索引或重写查询逻辑。
  • 解决:为慢查询添加合适索引,或拆分复杂查询为多个子查询,减少执行时间。

3. 监控集群资源与负载

  • 操作
    • 通过 TiDB 监控面板(Grafana)查看 TiDB/TiKV 节点的 CPU、内存、磁盘 I/O、网络延迟等指标。
    • 检查 TiKV 节点的 store.log,确认是否有 raft 日志异常(如 leader 丢失、心跳超时)。
    • 查看 TiDB 的 information_schema.processlist,确认是否有大量阻塞查询。
  • 解决
    • 若资源不足,扩容 TiDB/TiKV 节点或升级硬件配置。
    • 清理无效事务、优化锁冲突场景(如减少大事务、避免长事务)。

4. 验证网络连通性

  • 操作
    • 在 TiDB 节点上,使用 ping/telnet 测试与 TiKV 节点的网络连通性(重点检查端口 20160,TiKV 的客户端端口)。
    • 抓取网络包(如 tcpdump),分析是否存在丢包、重传等问题。
  • 解决:联系运维团队修复网络故障,或调整防火墙规则确保组件间通信正常。

5. 优化 SQL 语句

  • 操作
    • 检查报错 SQL 是否命中索引,避免全表扫描(如通过 SHOW INDEX FROM table 查看索引情况)。
    • 简化查询逻辑,避免子查询嵌套过深、大表 JOIN 等操作。
    • 对高频查询启用缓存(如 TiDB 的 SELECT ... CACHE 语法)。
  • 解决:根据执行计划优化索引,或使用分区表、列存(TiFlash)加速分析型查询。

用tiup 工具升级的时候 直接到8.5.2了,不会是个残次品吧

1 个赞

重置索引前有 admin check table 检查过这个表么?

检查过 ,显示是正常的,只能删除重建才有效