仪表板智能洞察的元数据存在哪些表里？一文看懂配置、结果和日志的分工

摘要

排查仪表板智能洞察问题时，最容易混淆的就是：页面上明明能正常看到洞察内容，但到了订阅推送、历史记录定位或异常分析阶段，却不知道该查哪张表。本文结合代码和表结构，梳理智能洞察相关的 4 张核心表，帮助你快速区分订阅配置、洞察结果、执行日志和页面映射的职责边界。

正文

在排查仪表板智能洞察问题时，很多同学都会遇到一个很典型的场景：页面里手动点击“智能洞察”能够正常看到结果，但到了订阅推送、历史记录排查或者异常定位阶段，却不知道应该先查哪张表。

造成这种困惑的一个关键原因是，智能洞察相关数据并不是集中存放在一张表里，而是分散在“订阅配置”“洞察结果”“执行日志”等不同层面。不同问题，关注的表也不一样。如果一开始就查错方向，排查效率会明显下降。

这篇文章结合实际代码和表结构，梳理仪表板智能洞察涉及的几张核心元数据表，帮助大家快速回答这几个常见问题：

• 智能洞察订阅配置存在哪里
• 智能洞察生成结果存在哪里
• 推送失败或超时时应该重点看哪里
• 页面、卡片和订阅之间的关系怎么定位

一、核心表总览

先看整体分工。

如果只想先建立一个整体认知，可以记住这三句话：

二、schedule：智能洞察订阅配置主表

如果你关心的是“这条智能洞察订阅是怎么配出来的”，第一张要看的就是 schedule。

智能洞察订阅和普通订阅共用同一套订阅体系，通过 sc_type 区分订阅类型。

1. sc_type 枚举值

也就是说，查智能洞察订阅时，核心过滤条件通常就是：

sc_type = 5

2. schedule 常用字段

这张表回答的是：这条智能洞察订阅是怎么定义出来的。

3. 示例 SQL

SELECT sc_id, resource_id, name, trigger_type, cron, enabled, ctime, utime
FROM schedule
WHERE is_del = 0
  AND sc_type = 5
ORDER BY utime DESC
LIMIT 20;

三、intelligent_insight_report：智能洞察结果内容表

如果你关心的是“智能洞察到底生成了什么内容”，重点要看 intelligent_insight_report。

这张表不是订阅配置表，而是智能洞察的结果表，主要保存洞察生成后的报告内容，供页面展示、历史查看和后续复用。

1. intelligent_insight_report 核心字段

这张表解决的是下面这些问题：

如果页面右侧已经能正常展示智能洞察内容，那么通常最终结果会落到这张表中。

2. 示例 SQL

SELECT report_id, resource_id, resource_type, analysis_id, u_id, ctime, utime
FROM intelligent_insight_report
ORDER BY utime DESC
LIMIT 20;

四、schedule_log：智能洞察订阅执行日志表

很多“页面正常、推送失败”的问题，真正的关键不在配置表，也不一定在结果表，而是在执行日志里。

这时要重点看 schedule_log。

1. schedule_log 常用字段

这张表回答的是：这次推送执行过程中到底发生了什么。

例如出现类似下面的报错时：

page.waitForFunction: Timeout 300000ms exceeded

通常更应该优先从执行链路和等待条件角度排查，而不是直接怀疑洞察结果内容本身。

2. 示例 SQL

SELECT l.sc_id, l.task_id, l.status, l.error_message, l.first_send_time, l.last_send_time
FROM schedule_log l
JOIN schedule s ON l.sc_id = s.sc_id
WHERE s.is_del = 0
  AND s.sc_type = 5
ORDER BY l.last_send_time DESC
LIMIT 20;

五、schedule_multicards_mapping：订阅和页面对象的关联关系

除了上面三张核心表外，智能洞察订阅还经常会涉及 schedule_multicards_mapping。

这张表更偏映射关系，适合处理“订阅到底挂在哪个页面上”这一类问题。

1. 主要关注点

当需要把订阅配置和实际页面对象串起来时，这张表通常会派上用场。

六、页面能看，订阅却失败，通常意味着什么？

这是实际排查里非常常见的一种现象：

这通常说明：

• 智能洞察本身的生成能力不一定有问题
• 失败点更可能出现在订阅执行链路
• 自动化环境和人工访问环境可能存在差异

常见原因可以概括为：

七、推荐排查顺序

实际定位问题时，建议按这个顺序查：

这个顺序的好处是，可以先判断“配置有没有问题”，再判断“结果有没有产出”，最后再聚焦“执行为什么失败”。

八、总结

仪表板智能洞察相关元数据并不是只存在一张表里，而是分成了几个职责明确的层次：

所以在实际排查时，可以优先记住这一组对应关系：

• 看配置，查 schedule
• 看结果，查 intelligent_insight_report
• 看失败原因，查 schedule_log
• 看关联对象，查 schedule_multicards_mapping

理解了这几张表的分工之后，智能洞察相关问题的定位路径通常会清晰很多，尤其是在“页面能看、订阅却失败”这类场景下，会更容易判断问题究竟落在配置、结果还是执行链路上。