【技巧分享】SQL 执行报错问题排查方法

有点东西

同样都是专业选手，你看看人家！

很棒的帖子，收藏一下。

解决报错信息，最好分析日志

一直想自己总结一下这块的思维导图

感谢官方文档团队为大家提供问题排查的方法！

期待在这个新板块继续和大家分享更多的问题排查文档！

这里再啰嗦一句：select last_trace_id() 在使用上有一些限制，必须要在在同一个 session 中，紧接着报错的 SQL，去执行 select last_trace_id()。 如果在报错 SQL 之后，已经执行了其他 SQL，或者已经退出对应 session，可以在日志里先通过 grep "ret=-errno" 或者直接 grep 你执行的 SQL 里的关键字，也是可获取到 trace_id 的。还有就是 OCP 白屏捞日志超级方便，且可以更便捷地选择日志级别和日志的时间范围，也是捞日志的一种好方法。

image1218×611 139 KB

参考：【如何提问】遇到 OBServer 中的非预期报错，应该如何发帖提问？

今天刚发现 show trace 命令还可以看到执行失败的 SQL，是在什么时候失败的。这可能对排查问题会有一些帮助，也一起在这里分享给大家。

比如下面这个例子，可以看到表不存在这个报错，让 SQL 在 resolver（解析）阶段就停下来了。说明是在 resolver 的检查时就发现了表不存在，然后就没有执行后面的东西了。个人理解 trace 树的最后一步就是出错的地方。

obclient> set ob_enable_show_trace = 1;
Query OK, 0 rows affected (0.00 sec)

obclient> insert into z0case(z0_test0,z0_test1) values('11:11:12', '11:11:10');
ERROR 1146 (42S02): Table 'test.z0case' doesn't exist

obclient> show trace;
+-------------------------------+----------------------------+------------+
| Operation                     | StartTime                  | ElapseTime |
+-------------------------------+----------------------------+------------+
| com_query_process             | 2025-05-09 10:19:39.621982 | 0.551 ms   |
| └── mpquery_single_stmt       | 2025-05-09 10:19:39.621988 | 0.534 ms   |
|     └── sql_compile           | 2025-05-09 10:19:39.621997 | 0.405 ms   |
|         ├── pc_get_plan       | 2025-05-09 10:19:39.622002 | 0.009 ms   |
|         └── hard_parse        | 2025-05-09 10:19:39.622063 | 0.315 ms   |
|             ├── parse         | 2025-05-09 10:19:39.622063 | 0.079 ms   |
|             └── resolve       | 2025-05-09 10:19:39.622170 | 0.180 ms   |
+-------------------------------+----------------------------+------------+
7 rows in set (0.01 sec)

顺哥要不要考虑在这个板块给大家介绍下怎么通过 obdiag 捞日志和分析问题？

思维导图很棒，看着就很清晰

太赞，保存做桌面。

过程很清晰

学习

太强了,学习

很棒的分享

赞赞赞

真棒

清洗的排查思路