使用TIDB查询sql时候 sql的执行失败

Hacker_AkXHVl7a · 2022 年9 月 2 日 07:09

SQL state [HY000]; error code [1105]; other error: [src/coprocessor/endpoint.rs:167]: WireError(OverRecursionLimit); nested exception is java.sql.SQLException: other error: [src/coprocessor/endpoint.rs:167]: WireError(OverRecursionLimit)

Kongdom · 2022 年9 月 2 日 08:06

能贴一下语句和tidb版本么？

Hacker_AkXHVl7a · 2022 年9 月 2 日 08:14

sql.txt (123.1 KB)

Hacker_AkXHVl7a · 2022 年9 月 2 日 08:15

Kongdom · 2022 年9 月 2 日 08:40

Kongdom · 2022 年9 月 2 日 08:42

有一说一，这应该是我见过最长的sql语句了，可以让应用层优化一下么~

wisdom · 2022 年9 月 2 日 08:46

应该是语句存在一定的问题，优化一下吧

Hacker_AkXHVl7a · 2022 年9 月 2 日 09:13

能从配置上面修改吗

Hacker_AkXHVl7a · 2022 年9 月 2 日 09:14

sql没问题就是好像是太长了导致的但是这个业务场景就是这样;想这能不能从TIDB配置方面修改一下

Kongdom · 2022 年9 月 2 日 09:15

什么业务场景要写12w字长度的sql呀

Hacker_AkXHVl7a · 2022 年9 月 2 日 09:21

一个是因为表的字段太多了有1600多个业务场景是:在这表里面通过sql去查询表里面的空值的字段这里面用了函数计算叠加起来就很多了再加上一些判断条件
这个只能从sql层面去优化吗?可不可以从TIDB 给定的大小进行修改啊

Kongdom · 2022 年9 月 2 日 09:22

写这么长，只是为了取出非空的记录数么？不能从源头控制不允许为空么~

Hacker_AkXHVl7a · 2022 年9 月 2 日 09:26

因为数据源那边是对接的是商家源数据不能动

Kongdom · 2022 年9 月 2 日 09:27

这个语句是要取出所有字段不为空的记录数是吧？

Kongdom · 2022 年9 月 2 日 09:32

试试这个变量，看看能不能成
https://docs.pingcap.com/zh/tidb/stable/system-variables#cte_max_recursion_depth

Hacker_AkXHVl7a · 2022 年9 月 2 日 10:37

这个是要在配置文件里面处理修改吗

forever · 2022 年9 月 3 日 09:40

会话级别
SET cte_max_recursion_depth = 1000;
全局级别
SET GLOBAL cte_max_recursion_depth = 1000;

alfred · 2022 年9 月 3 日 15:25

这个sql太复杂了，数据库处理起来未必高效或者合适，建议从应用层优化下

system · 2022 年11 月 2 日 15:26

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