统计口径：昨日全天 2026-10-25 00:00:00 ~ 23:59:59（Asia/Shanghai），ES@timestamp按 UTC+8 换算为[2026-10-25T00:00:00+08:00, 2026-10-26T00:00:00+08:00)。
环境：staging。数据来源：MCP addcnes_slow_logs/es_search（索引mysql_slow-*）+describe_schema/explain/show_variables（全程只读）。
| 指标 | 数值 |
|---|---|
| 统计日期 | 2026-10-25（昨日有数据，未回退前日） |
| 慢日志文档数（抽样上限 2 万条，实际 1 页拉全） | 1,352 条 |
| SQL 指纹模式数 | 576 个 |
| Top10 平均耗时 | ~572 秒 |
| Top10 构成 | 9 条 mysqldump 全表导出（user=backup）+ 1 条 COMMIT |
| 触发深度分析的高频模式 | 1 个（COMMIT;，179 条 / 累计 771s） |
总体结论：昨日 staging 慢查询 Top10 几乎全部为 backup 用户的 mysqldump 全表导出（备份流量，属预期行为）；业务侧最突出的两个问题是 ① 8891 实例 COMMIT 提交耗时（单次最高 283s，双一配置 + 低 io_capacity），② hk8591 财务流水表 sub_account 隐式类型转换导致索引失效（单条 20~33s）。
| # | 耗时(s) | 锁等待(s) | 扫描行数 | 用户 | 实例/主机 | SQL 摘要 | 慢因判定 |
|---|---|---|---|---|---|---|---|
| 1 | 1667.34 | 0.0005 | 5,693,964 | backup | staging/8891 (LAN_addcn_84) | SELECT /*!40001 SQL_NO_CACHE */ * FROM t8891.t_item_modi_histories | 备份全表导出（全表扫描 502 万行，数据量 ~14G） |
| 2 | 1197.96 | 0.0003 | 3,290,762 | backup | staging/8891 (LAN_addcn_84) | SELECT ... * FROM t8891.t_sele_item_infos | 备份全表导出（300 万行，~20G） |
| 3 | 557.45 | 0.0003 | 16,681 | backup | staging/8891 (LAN_addcn_84) | SELECT ... * FROM t8891.yahoo_car_details | 备份全表导出（宽行大字段，~18M/6270 行仍耗 557s，行均 ~84ms，疑含超大 text 列） |
| 4 | 417.78 | 0.0004 | 39,105,741 | backup | staging/8891 (LAN_addcn_84) | SELECT ... * FROM t8891.t_subscription_push | 备份全表导出（3,953 万行，仅 4 列 ~33G） |
| 5 | 305.08 | 0.0000 | 30,368,679 | backup | staging/100-slave (LAN_addcn_46) | SELECT ... * FROM t591.t1_daily_report | 备份全表导出（2,885 万行，~7G） |
| 6 | 293.59 | 0.0000 | 62,094,219 | backup | staging/TD-slave (LAN_addcn_51) | SELECT ... * FROM anylink.access_audit | 备份全表导出（5,793 万行审计日志，~72G） |
| 7 | 283.34 | 0.0000 | 0 | sonic | staging/8891 (LAN_addcn_84) | commit; | 事务提交慢（非查询，见深度分析） |
| 8 | 281.62 | 0.0003 | 22,929,970 | backup | staging/8891 (LAN_addcn_84) | SELECT ... * FROM t8891.t_sele_item_photos | 备份全表导出（2,180 万行，~80G） |
| 9 | 245.65 | 0.0000 | 56,896,467 | backup | staging/TD-slave (LAN_addcn_51) | SELECT ... * FROM anylink_corp.access_audit | 备份全表导出（5,212 万行审计日志，~65G） |
| 10 | 231.33 | 0.0001 | 868,479 | backup | staging/8891 (LAN_addcn_84) | SELECT ... * FROM t8891.telescope_entries | 备份全表导出（Laravel Telescope 85 万行，~868M） |
EXPLAIN 均已执行（备份类为access_type: ALL全表扫描，符合 mysqldump 预期，无需加索引）；#7commit为事务语句，EXPLAIN 不适用，改查show_variables/show_status（见第四节）。
| # | 指纹（SQL 骨架） | 条数 | 平均(s) | 最大(s) | 累计(s) | 用户 | server_name |
|---|---|---|---|---|---|---|---|
| 1 | COMMIT; | 179 | 4.31 | 283.34 | 771 | addcn8891_test / bee / eagle / jumper_dev / sonic | LAN_addcn_27 / 37 / 84 |
| 2 | SHOW ENGINE INNODB STATUS; | 98 | 1.39 | 2.24 | 136 | jmysql | LAN_addcn_27 / 40_3308 |
| 3 | # administrator command: Ping; | 73 | 1.39 | 2.16 | 101 | 8591 / jmysql | LAN_addcn_27 / 46 |
| 4 | select i.*, COALESCE(v.views_30d,0) ... （591 房源列表联表查询） | 68 | 1.16 | 1.38 | 79 | a591 | LAN_addcn_46 |
| 5 | select id, buyer_id, completed_at from h8_orders where buyer_id in (...) | 48 | 2.48 | 15.29 | 119 | 8591 | LAN_addcn_27_3307 |
| # | 指纹（SQL 骨架） | 条数 | 平均(s) | 最大(s) | 累计(s) | 用户 | 备份模式 |
|---|---|---|---|---|---|---|---|
| 1 | SELECT /*!40001 SQL_NO_CACHE */ * FROM t8891.t_item_modi_histories | 1 | 1667.34 | 1667.34 | 1667 | backup | ✅ 是（不触发深度分析） |
| 2 | SELECT ... * FROM t8891.t_sele_item_infos | 1 | 1197.96 | 1197.96 | 1198 | backup | ✅ 是 |
| 3 | COMMIT; | 179 | 4.31 | 283.34 | 771 | 多业务账号 | ❌ 否（触发深度分析） |
| 4 | SELECT sum(after_amount-before_amount) ... FROM h8_finance_account_logs where user_id=? and sub_account=? | 17 | 32.96 | 109.04 | 560 | 8591 | ❌ 否（未达阈值，已补查，见 3.3） |
| 5 | SELECT ... * FROM t8891.yahoo_car_details | 1 | 557.45 | 557.45 | 557 | backup | ✅ 是 |
其余进入累计耗时前列的还有：h8_finance_account_logs取最新一条（18 条 / 平均 19.5s / 累计 351s）、t_subscription_push/t1_daily_report备份导出等。备份模式条数（各 1 条）与常规持平，无环比异常，不做深度分析。
COMMIT;（179 条，累计 771s，触发条件：条数 > 100）⚠️sync_binlog = 1、innodb_flush_log_at_trx_commit = 1（双一配置，每次提交都 fsync）innodb_io_capacity = 200（偏低）Innodb_data_fsyncs ≈ 1.02 亿、Innodb_os_log_fsyncs ≈ 5,680 万（fsync 压力大）Threads_running = 2、行锁等待 0（排除锁等待）innodb_flush_log_at_trx_commit 调为 2、sync_binlog 调为 100（staging 非交易生产库，风险可接受；生产 8591 已是 2/0 组合，可参照）；innodb_io_capacity 提升至磁盘实际能力（SSD 建议 2000+）；h8_finance_account_logs 财务流水查询（未达阈值但单条 20~109s，主动补查）SELECT sum(after_amount-before_amount) FROM h8_finance_account_logs WHERE user_id=1030996 AND sub_account=11（17 条 / 平均 32.96s / 最大 109.04s）及同条件 ORDER BY id DESC LIMIT 1（18 条 / 平均 19.52s）。表行数约 1,359 万。idx_user_sub_account_id (user_id, sub_account, id DESC)、asacca (user_id, sub_account, course, created_at) —— 索引本身是齐的。possible_keys 命中两个索引，但 used_key_parts 只有 user_id（key_length=8），sub_account 条件被降级为索引条件下推（ICP），预估扫描 21,126 行；ORDER BY id DESC LIMIT 1 那条更是放弃二级索引、走了 PRIMARY 反向全扫过滤。sub_account 列是 char(2)，而 SQL 传的是整数 sub_account = 11。MySQL 对「字符串列 = 整数」会在列侧做 CAST，该列上的等值条件无法作为索引 ref/range 使用，只能用到 user_id 一个前缀，再逐行回表过滤，1,359 万行大表上单用户命中数万行流水时耗时 20~110s。sub_account = '11'（ORM 侧将该查询参数绑定为字符串，或模型中把 sub_account cast 为 string）。修复后 idx_user_sub_account_id 可完整使用 (user_id, sub_account, id DESC) 三段：sum 查询扫描行数从 ~2.1 万降至该子账户实际行数，limit 1 查询可直接反向索引定位首行，预计降至毫秒级。h8_finance_account_logs 的 sub_account = 11 → sub_account = '11'，涉及 h8 平台余额汇总与最新流水两处查询（应用侧 ORM 参数绑定）。收益：单条 20~109s → 毫秒级，全天减少 ~15 分钟慢查询。innodb_flush_log_at_trx_commit=2、sync_binlog=100），提升 innodb_io_capacity，并错峰备份与批量任务。收益：消除 179 次/天的 COMMIT 慢日志（累计 771s）及业务写阻塞。--single-transaction + 限速（--max-allowed-packet/throttle）并避开业务高峰。大表（access_audit 5,700 万行、t_sele_item_photos 2,180 万行）可评估分区/归档以缩短备份窗口。buyer_id IN (...) 查询（48 条 / 平均 2.48s / 最大 15.29s）：IN 列表较长时耗时上升，建议确认 buyer_id 有索引且控制单批 IN 数量（分批 ≤ 500）。SHOW ENGINE INNODB STATUS / Ping 进入慢日志多为监控采集行为（jmysql），耗时 1~2s 与实例 IO 抖动相关，随建议 2 缓解。es_slow_logs（Top10）、es_search（mysql_slow-*，1,352 条全量）、connect/describe_schema/explain/count_estimate/show_variables/show_status/search_schema（全程只读，未执行任何写操作、未 kill、未改配置、未 git 提交）。.agents/scripts/slow_report_20261025_run.py。