请问下读写冲突,查询慢的问题

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】

【概述】 场景 + 问题概述
有个业务表是这么设计的,A、B、C三张表,B是A的子表,C是B的子表。
select B.xxx,C.xxx from
A
left join B on A.id=B.pid
left join C on B.id=C.pid
where A.id in (xxx);
根据运维监控,当有
delete form C where C.pid in(xxx,xxxxx,xxxx);同时执行。
上面那个查询很慢,30多秒,主要是第二阶段慢。数据量大概1000+的样子。
可是读的SQL和删的SQL所对应的数据不是同一批数据,在业务上来说是没有冲突的。
请问读、删都用in会有读写冲突吗?该如何优化?
【背景】 做过哪些操作

【现象】 业务和数据库现象

【问题】 当前遇到的问题,参考 AskTUG 的 Troubleshooting 读性能慢-慢语句

【统计信息是否最新】

    【执行计划内容】

    【 SQL 文本、schema 以及 数据分布】

【业务影响】

【TiDB 版本】

【附件】 相关日志及监控(https://metricstool.pingcap.com/)

  • TiUP Cluster Display 信息
  • TiUP CLuster Edit config 信息
  • TiDB-Overview Grafana监控
  • TiDB Grafana 监控
  • TiKV Grafana 监控
  • PD Grafana 监控
  • 对应模块日志(包含问题前后 1 小时日志)
1赞

如果两个 SQL 对应的数据范围不是同一批的话,正常是不会被冲突到的。
可以看一下 SELECT 语句慢的时候,该语句的 explain analyze 吗

表是旧的,没加索引,那个查询走全表扫描了,我加上索引观察下

如果删除数据中的c.pid和查询中 a.id没有关联关系,是不会读写冲突的。如果有冲突,可以部署tiflash组件来解决。把查询请求路由到tiflash上。

哦哦 全表扫描的话,确实会让这个 select 也受到 delete 产生的大量无用数据版本的影响

你这个情况是不是全表扫的读锁把后面的update的写锁排斥了,这个时间长是等锁的过程