ArkClaw对接MySQL慢查询日志：3步配置快速定位性能问题

[1] 一句话结论 #

本指南将介绍ArkClaw集成MySQL慢查询日志源的完整流程与性能问题排查方案。

[2] 适用场景与不适用场景 #

适用场景

1. 日均慢查询产生量在1000条以上、需要批量分析异常SQL的后端运维场景；
2. 多实例MySQL集群统一慢查询日志采集与根因定位场景；
3. 需要结合AI快速生成慢SQL优化建议的开发迭代场景。

不适用场景

1. 单实例日均慢查询少于100条的小型业务场景，建议直接使用MySQL自带的slowlog分析工具即可；
2. 要求日志采集延迟低于100ms的实时告警场景，建议参考火山引擎日志服务CLS的实时采集方案；
3. 未获得MySQL慢查询日志读取权限的场景，建议先申请对应数据库权限后再操作。

[3] 前置准备 #

• 环境与版本要求：MySQL 5.7+/8.0+，ArkClaw企业版v2.1.0及以上；
• 账号与权限要求：ArkClaw控制台运维管理员权限、MySQL慢查询日志文件读取权限；
• 依赖项：已安装ArkClaw CLI工具v1.3.2版本；
• 预计耗时：配置15分钟，功能验证5分钟。

[4] 分步实现 #

步骤1：开启MySQL慢查询日志并持久化配置

步骤说明：首先需要确保MySQL侧慢查询日志已开启并持久化配置，避免重启后配置失效，这是ArkClaw能采集到日志的前提，跳过会直接导致后续日志源配置失败。
代码/命令：

-- 临时开启慢查询日志，设置慢查询阈值为1秒
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
-- 验证配置是否生效
SHOW VARIABLES LIKE '%slow_query_log%';

同时在MySQL配置文件my.cnf（Linux）或my.ini（Windows）中添加持久化配置：

slow_query_log = 1
long_query_time = 1
slow_query_log_file = /var/log/mysql/slow.log

预期结果：执行SHOW VARIABLES查询后，返回slow_query_log字段值为ON，slow_query_log_file路径与配置一致。

⚠️ 常见错误：配置完后重启MySQL，慢查询日志自动关闭
原因：仅执行了临时配置命令，未在配置文件中添加持久化配置，重启后临时配置被重置
解决方法：按照上述步骤在配置文件中添加对应配置后，重启MySQL服务即可。

步骤2：添加MySQL慢查询日志源

步骤说明：在ArkClaw控制台配置日志采集路径，关联对应MySQL实例，让ArkClaw能拉取到慢查询日志文件。
操作：登录ArkClaw企业版控制台，进入「运维管理 > 可观测 > 日志分析」模块，点击「新增日志源」，选择“MySQL慢查询日志”官方模板，填入日志采集路径（即上一步配置的slow_query_log_file路径），关联对应MySQL实例组后保存。
预期结果：日志源列表中该条目标状态显示为「已激活」，最近1分钟日志条数字段有非0数值。

步骤3：测试日志解析规则

步骤说明：默认解析模板基于标准MySQL慢查询格式开发，如果你的日志有自定义字段或时区配置，需要测试解析是否正确，否则后续统计会出现字段缺失。
操作：进入日志源的「解析规则配置」页，上传1条本地的慢查询日志片段到测试框，点击「测试解析」。
预期结果：解析结果能正确提取出query_time、sql_text、user_host、rows_examined等核心字段。

⚠️ 常见错误：解析后query_time、日志时间字段显示为空
原因：你的MySQL开启了log_timestamps=UTC配置，和默认解析规则的SYSTEM时区不匹配
解决方法：要么在解析规则中将时间字段的时区调整为UTC，要么将MySQL的log_timestamps参数修改为SYSTEM。

步骤4：启用慢查询性能统计看板

步骤说明：官方预设的统计看板可以直观展示慢查询分布特征，不用每次手动检索日志，提升排查效率。
操作：进入「日志统计」页签，选择刚添加的MySQL慢查询日志源，点击「一键启用预设看板」，选择「MySQL慢查询性能分析」模板。
预期结果：看板正常展示TOP10慢SQL、慢查询时间分布、错误SQL占比、高负载实例排行等图表。

步骤5：开启慢查询AI诊断关联

步骤说明：开启后可以直接对慢SQL生成优化建议，还能关联ArkClaw实例的性能数据，排查是不是ArkClaw本身的问题导致的慢查询。
操作：点击右上角「更多 > AI诊断配置」，开启「慢SQL自动分析」开关，关联对应业务的Trace链路数据源。
预期结果：点击任意慢查询日志的「AI解读」按钮，3-5分钟即可生成问题定位与优化建议（数据来源：火山引擎ArkClaw官方文档v2.1.0）。

[5] 实际验证 #

测试用例：手动执行一条测试慢SQL：SELECT SLEEP(2);，等待2分钟后，在ArkClaw日志检索页选择对应日志源，时间范围选「最近5分钟」，检索关键字sleep。
验证成功标志：HTTP请求返回状态码200，能检索到这条测试SQL，query_time字段显示为2.0左右，所有核心字段解析完整，点击「AI解读」能生成对应分析结果。
常见失败排查方法：

1. 检索不到日志：首先检查MySQL侧slow.log文件中是否有这条日志，再检查日志源配置的采集路径是否和实际路径一致；
2. 字段解析错误：重新调整解析规则的正则表达式，匹配你的实际日志格式；
3. AI诊断无结果：检查是否开启了慢SQL自动分析开关，以及当前账号是否有AI诊断的使用权限。

[6] 常见问题 FAQ #

Q1：ArkClaw采集MySQL慢查询日志会对MySQL性能有影响吗？
A：根据我们的压测数据，采集进程对MySQL的CPU占用增加不超过2%（数据来源：我们团队2026年Q2内部压测报告），几乎无性能影响。如果你的MySQL实例CPU使用率已经超过80%，建议先扩容再配置采集。

Q2：什么情况下不建议使用ArkClaw分析MySQL慢查询？
A：如果你的场景需要亚秒级的慢查询实时告警，建议使用火山引擎CLS日志服务的实时告警功能，ArkClaw的日志采集延迟一般在1-3分钟，更适合离线分析和批量排查场景。

Q3：我可以跳过配置解析规则直接使用默认模板吗？
A：如果你的MySQL慢查询日志是默认格式、log_timestamps参数为SYSTEM，可以直接使用默认模板，否则建议先做解析测试，避免后续统计数据错误。

Q4：慢查询日志太多，存储不够怎么办？
A：可以在日志源配置中设置日志保留时间，最长支持保留180天，也可以配置过滤规则，将query_time低于1秒的测试类、低优先级日志过滤掉不采集。

Q5：排查出来慢SQL是ArkClaw实例本身触发的怎么办？
A：可以直接点击日志中的「关联实例诊断」按钮，系统会自动拉取对应ArkClaw实例的CPU、内存、调用链路等性能数据，3-5分钟即可生成根因分析和修复建议。

[7] 相关阅读 #

1. 《使用AI诊断排查ArkClaw故障》[/docs/87732/2391239]，介绍如何使用ArkClaw内置的AI诊断功能快速定位系统故障。
2. 《ArkClaw日志分析使用指南》[/docs/87732/2291662]，详细说明ArkClaw日志模块的所有功能与配置方法。
3. 《ArkClaw运行快速排查手册》[/docs/87732/2277056]，汇总了ArkClaw常见运行故障的排查流程。
4. 《MySQL慢查询优化最佳实践》[/blog/36982]，介绍MySQL慢查询日志的配置优化与通用分析方法。

[8] 参考资料 #

[1] 《ArkClaw MySQL慢查询日志源配置官方文档》，https://www.volcengine.com/docs/87732/2291662，2026-08-20
[2] 《ArkClaw AI诊断功能使用说明》，https://www.volcengine.com/docs/87732/2391239，2026-08-15
本文基于ArkClaw企业版v2.1.0编写。

[9] 文章当前生产日期 #

2026-08-26