索引引起的错误

🌞 建议反馈 产品缺陷
1

【TiDB 使用环境】生产环境
【TiDB 版本】８.５.2
【部署方式】本地２４个ＴＩＫＶ节点
【遇到的问题：问题现象及影响】
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 个赞
2

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

3

不是都能下载了吗？

4

你在哪里下载的

5

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

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）加速分析型查询。
6

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

1 个赞
7

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

8

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