← 返回文章列表
架构治理

智能顾问 CloudQ 架构治理实验报告（二）：CDB 数据库层慢查询

腾讯云智能顾问 2026/4/3
智能顾问 CloudQ 架构治理实验——CDB 数据库层异常定位

图：基于诊断矩阵的实验覆盖维度 — 数据库层 x 性能效率/成本优化/可靠性，应用层 x 性能效率

一、实验概述

本文是 《腾讯云智能顾问(TSA)架构评估实战》 计划的第二轮架构治理实验报告，完整记录了 CDB 数据库层故障注入的全过程。通过移除 SQL 分页限制模拟无限制全表查询，验证智能顾问 CloudQ 对数据库性能问题的检测能力。

实验目标验证智能顾问 CloudQ 能否检测到 SQL 查询缺陷导致的数据库性能退化
故障类型移除 LIMIT/OFFSET 分页 + 查询 content 大字段（模拟无限制全表扫描）
影响层次数据库层（CDB MySQL）→ 应用层（Node.js）
涉及支柱性能效率、成本优化、可靠性
实验时间2026-04-03 22:35 ~ 22:42（CST）
实验结果故障生效但未触发慢查询阈值，揭示了"温水煮蛙"型性能隐患的检测难点

二、诊断矩阵定位

架构层 性能效率 成本优化 可靠性
数据库层 (CDB)■ 命中
全表扫描 + 大字段查询		■ 命中
资源消耗异常增加		■ 命中
高负载下连接池可能饱和
应用层 (Node.js)■ 命中
响应时间翻倍、分页失效		——

三、Step 1 — 基线采集

3.1 服务基线

=== [2026-04-03 22:35:11] Baseline ===
$ curl -s -w '\nTime: %{time_total}s' http://localhost/health
{"status":"ok","timestamp":"2026-04-03T14:35:11.458Z"}
Time: 0.001684s

$ curl -s -o /dev/null -w 'Time: %{time_total}s, Size: %{size_download}B, Status: %{http_code}' http://localhost/
Time: 0.003327s, Size: 9891B, Status: 200

3.2 智能顾问 CloudQ CDB 日志基线

输入：

智能顾问 CloudQ: "上海地域，搜索cloud_sh_cdb_topic日志主题最近1小时的慢查询日志"

输出：

时间范围：21:35 ~ 22:35 | 检索条件：全量检索（*）

结果：最近 1 小时内未检索到任何慢查询日志。

该主题由 TencentDB-MySQL 自动投递。数据库运行健康，无慢查询。

四、Step 2 — 注入 CDB 故障

4.1 代码变更

文件：/opt/tech-blog/models/article.js

// 修改前
const [rows] = await pool.query(
  'SELECT id, title, summary, cover_url, category, author, published_at
   FROM articles ORDER BY published_at DESC LIMIT ? OFFSET ?',
  [pageSize, offset]
);

// 修改后（注入故障）
const [rows] = await pool.query(
  'SELECT id, title, summary, content, cover_url, category, author, published_at
   FROM articles ORDER BY published_at DESC',
  []
);

4.2 重启并验证

[2026-04-03 22:36:46] Restarting with CDB fault...
$ systemctl restart tech-blog

=== Health Check ===  Time: 0.002s ✅
=== Homepage ===     Time: 0.003s ⚠️ 可访问但有隐患

=== 分页检查 ===
Page 2 articles: 12  ❗ 所有文章都在每页显示
Pagination: MISSING  ❗ 分页控件消失

=== 压力测试（30 次无缓存请求）===
Req 1:  0.009s  (基线 0.003s → ~7ms，翻倍)
Req 10: 0.008s
Req 20: 0.007s
Req 30: 0.006s
平均响应: ~7ms（基线 ~3ms，增长 133%）

五、Step 3 — 智能顾问 CloudQ 故障检测

5.1 CDB 慢查询日志检索

输入：

智能顾问 CloudQ: "上海地域，搜索cloud_sh_cdb_topic日志主题最近10分钟的所有日志"

输出：

智能顾问 CloudQ CDB 日志检索结果

地域ap-shanghai
日志主题cloud_sh_cdb_topic
时间22:30 ~ 22:40
命中0 条 — 未触发慢查询阈值

该主题仅当 SQL 执行时间超过 long_query_time（默认 10 秒）时才会记录。当前数据量较小（~12 篇文章），即使全表扫描也不足以触发慢查询记录。

5.2 应用日志检索

输入：

智能顾问 CloudQ: "上海地域，搜索shweb日志主题最近10分钟的ERROR日志"
SessionID: d77t2gd992eqlg44p8t0（沿用）

输出：

智能顾问 CloudQ shweb 日志检索结果

命中 6 条 ERROR，涉及 2 台主机、2 类错误：

错误类型一：上游服务连接拒绝（2 条）

时间主机错误
22:36:46172.17.0.6connect() failed (111: Connection refused) — upstream http://127.0.0.1:3000/

说明：服务重启瞬间产生的短暂连接中断，与 CDB 故障本身无关。

错误类型二：静态资源缺失（4 条）

另一台 CVM 上的图片 404（已知问题），与 CDB 故障无关。

六、Step 4 — 回滚恢复

[2026-04-03 22:42:07] Rollback & Recovery

$ cp /opt/tech-blog/models/article.js.bak /opt/tech-blog/models/article.js
$ systemctl restart tech-blog

=== Recovery Verification ===
Health: Time=0.001880s ✅
Homepage: Time=0.003003s, Status=200 ✅
分页功能恢复正常，服务完全恢复。

七、实验结果总结

7.1 全流程数据对比

指标 基线 故障期间 恢复后
首页响应时间0.003s ✅~0.007s ⚠️0.003s ✅
响应时间增长—+133%—
分页功能正常 ✅失效 ❌正常 ✅
CDB 慢查询日志0 条0 条（未触发阈值）0 条
智能顾问 CloudQ 应用日志3 条（图片404）6 条（+重启拒连）—

7.2 智能顾问 CloudQ 检测能力评估

检测维度 是否检测到 详情
CDB 慢查询日志⚠️ 未触发数据量较小（~12 篇），全表扫描未超过 long_query_time 默认 10s 阈值
应用日志分析✅ 是检测到服务重启时的 Connection refused 错误，并能区分不同主机和错误类型
架构评估N/A基线评估 82/100，该类代码层面的 SQL 缺陷不会直接反映在云资源评估中

7.3 关键发现

  1. "温水煮蛙"型性能隐患最难检测：响应时间从 3ms 涨到 7ms（+133%），但未触发任何告警阈值。这类问题在数据量较小时"无害"，但随着数据增长会急剧恶化
  2. CDB 慢查询阈值是双刃剑：默认 10s 阈值太高，导致许多实际影响用户体验的慢查询不会被记录。建议调低至 1~3 秒
  3. 分页失效是可见的功能故障：移除 LIMIT/OFFSET 导致所有文章在一页显示、分页控件消失。这类功能故障需要 UI 自动化测试来发现
  4. 架构评估与日志分析的盲区：当故障严重度不足以触发慢查询阈值，且不产生 ERROR 日志时，需要配合 APM（应用性能监控）来检测响应时间的异常增长

7.4 与实验一对比

对比维度 实验一（Redis） 实验二（CDB）
故障层次缓存层数据库层
故障严重度█ 服务完全不可用█ 性能退化 + 功能异常
CLS 日志检测✅ 20+ 条 ETIMEDOUT⚠️ 未触发慢查询阈值
响应时间>30s 超时~7ms（+133%）
故障可见性高（服务完全不可用）低（隐式性能退化）

7.5 架构治理建议

  • 调低 CDB 慢查询阈值：将 long_query_time 从默认 10s 调低到 1~3s，确保影响用户体验的慢查询能被记录
  • SQL Review 纳入 CI/CD：在代码审查中强制检查所有 SELECT 语句是否包含 LIMIT
  • 接入 APM 监控：配合应用性能监控（如腾讯云 APM）检测响应时间的异常增长，弥补慢查询阈值的盲区
  • 定期运行 智能顾问 CloudQ 双维度巡检：架构评估 + CLS 日志分析，同时关注慢查询数和响应时间趋势
← 返回文章列表