@timestamp UTC 换算为 [2026-11-01T00:00+08:00, 2026-11-02T00:00+08:00)）es_slow_logs / es_search，env=staging）mysql_slow-*（staging ES，经 MCP addcn 服务）；表结构/执行计划经 MCP connect → describe_schema → explain → disconnect 只读获取| 指标 | 值 |
|---|---|
| 当日慢日志文档数（模式分析样本） | 2,028 条（单页拉全，未超 5000） |
| SQL 指纹数 | 636 个 |
| Top10 中备份导出（user=backup） | 9 条 |
| Top10 中业务/其他 | 1 条（commit;，user=sonic，297s） |
| 单条最慢 | SELECT * FROM t8891.t_item_modi_histories（backup，2030s） |
| 备份模式累计耗时（可见 Top 指纹） | ≈ 4,236s+（全量 mysqldump，见高频表标注） |
昨日（11-01）staging 有数据，未触发前日回退。
| # | 耗时(s) | Lock(s) | rows_sent/Examined | user | 实例/服务器 | SQL（截断） | 慢因判定 |
|---|---|---|---|---|---|---|---|
| 1 | 2030.2 | 0.0003 | 5,693,964 / 5,693,964 | backup | staging/8891 (LAN_addcn_84) | SELECT /*!40001 SQL_NO_CACHE */ * FROM t8891.t_item_modi_histories | 备份全表导出（EXPLAIN: ALL，全扫 502 万行，cost 2.18M） |
| 2 | 1228.4 | 0.0002 | 3,290,762 / 3,290,762 | backup | staging/8891 | SELECT ... * FROM t8891.t_sele_item_infos | 备份全表导出（ALL，277 万行） |
| 3 | 576.6 | 0.018 | 16,681 / 16,681 | backup | staging/8891 | SELECT ... * FROM t8891.yahoo_car_details | 备份全表导出（ALL，宽行：6,270 行耗时 576s，单行极大 BLOB/TEXT） |
| 4 | 401.0 | 0.0005 | 22,929,970 / 22,929,970 | backup | staging/8891 | SELECT ... * FROM t8891.t_sele_item_photos | 备份全表导出（ALL，2,180 万行照片表） |
| 5 | 376.5 | 0.0004 | 39,105,741 / 39,105,741 | backup | staging/8891 | SELECT ... * FROM t8891.t_subscription_push | 备份全表导出（ALL，3,953 万行） |
| 6 | 322.1 | 0.0002 | 14,274,350 / 14,274,350 | backup | staging/8891 | SELECT ... * FROM t8891.t_member_ips | 备份全表导出（ALL，1,386 万行） |
| 7 | 311.0 | 0.0000 | 30,506,180 / 30,506,180 | backup | staging/100-slave (LAN_addcn_46) | SELECT ... * FROM t591.t1_daily_report | 备份全表导出（ALL，2,885 万行） |
| 8 | 300.9 | 0.0002 | 9,328 / 9,328 | backup | staging/8891 | SELECT ... * FROM t8891.save_car_details | 备份全表导出（宽行：4,033 行耗时 301s，单行 BLOB 极大） |
| 9 | 297.2 | 0.0000 | 0 / 0 | sonic | staging/8891 | commit; | 大事务提交：redo 刷盘耗时长（事务内累积大量写） |
| 10 | 293.9 | 0.053 | 414,726 / 414,726 | backup | staging/8891 | SELECT ... * FROM t8891.t_search_all_deal_items_thumb | 备份全表导出（ALL，25 万行宽行） |
小结：Top10 中 9 条为 mysqldump 全表导出（user=backup），集中在 8891 实例；EXPLAIN 全部为 ALL 全表扫描属预期（无 WHERE）。业务侧唯一入榜的是 commit;（297s），指向超大事务。
样本 2,028 条 / 636 指纹（search_after 翻页，1 页取全）。「按累计耗时」表包含备份模式（单独标注）。
| # | 条数 | 平均(s) | 最大(s) | 累计(s) | 用户 | 服务器 | 指纹（截断） | 备注 |
|---|---|---|---|---|---|---|---|---|
| 1 | 312 | 4.52 | — | 1410.2 | addcn8891_test/bee/eagle/jumper/jumper_dev/sonic | LAN_addcn_27/37/84 | commit; | ⚠ 触发深度分析 |
| 2 | 254 | 1.63 | — | 414.4 | jmysql | LAN_addcn_27_3307/37/40_3308 | show engine innodb status; | ⚠ 触发深度分析（监控探针） |
| 3 | 148 | 1.60 | — | 236.6 | 8591/jmysql | LAN_addcn_27/46 | # administrator command: Ping; | ⚠ 触发深度分析（连接池 Ping） |
| 4 | 91 | 1.61 | — | 146.8 | 8591 | LAN_addcn_27 | rollback; | 未达阈值（100 条） |
| 5 | 71 | 1.16 | — | 82.5 | a591 | LAN_addcn_46 | select i.*, coalesce(v.views_30d,?) ... from t_...（商品列表联查） | 未达阈值 |
| # | 条数 | 平均(s) | 累计(s) | 用户 | 服务器 | 指纹（截断） | 备注 |
|---|---|---|---|---|---|---|---|
| 1 | 1 | 2030.2 | 2030.2 | backup | LAN_addcn_84 | select * from t8891.t_item_modi_histories | 🔖 备份模式，不深度分析 |
| 2 | 312 | 4.52 | 1410.2 | 多业务账号 | LAN_addcn_27/37/84 | commit; | ⚠ |
| 3 | 1 | 1228.4 | 1228.4 | backup | LAN_addcn_84 | select * from t8891.t_sele_item_infos | 🔖 备份 |
| 4 | 31 | 22.02 | 682.5 | 8591 | LAN_addcn_27_3307 | select sum(after_amount-before_amount) ... from h8_finance_account_logs where user_id=? and sub_account=? | 累计未达 30min 阈值，但单条均值 22s，已补充 DDL+EXPLAIN（见下） |
| 5 | 1 | 576.6 | 576.6 | backup | LAN_addcn_84 | select * from t8891.yahoo_car_details | 🔖 备份 |
（另一值得注意：select * from h8_finance_account_logs where user_id=? and sub_account=? order by id desc limit ?，15 条 / avg 34.0s / 累计 509.3s，同表同根因，一并分析。）
commit; — 312 条 / avg 4.52s / 累计 23.5 分钟 ⚠commit 本身耗时 = 该事务 redo 刷盘 + binlog 刷盘 + 可能的组提交排队。312 次均值 4.5s、且第 9 名有一条 297s 的 sonic commit，说明存在「应用把大量写操作攒在一个长事务里提交」的用法（与 backup 大导出同窗口运行也会拉长组提交队列）。innodb_flush_log_at_trx_commit / sync_binlog staging 配置是否为 1/1（测试环境可放宽为 2/0 以降低每次 commit 的 fsync 成本）；show engine innodb status; — 254 条 / avg 1.63s ⚠LOCK_wait 相关内部锁并输出完整 engine 状态，实例繁忙/有大事务时本身就会慢。sys.innodb_buffer_pool_by_table 等）替代逐秒 SHOW ENGINE INNODB STATUS。# administrator command: Ping; — 148 条 / avg 1.60s ⚠h8_finance_account_logs（hk8591 库，未达条数阈值但均值 22~34s，主动跟进）PRIMARY KEY (id)KEY asacca (user_id, sub_account, course, created_at)KEY index (receipt_no)KEY idx_user_sub_account_id (user_id, sub_account, id DESC)SUM(after_amount-before_amount) ... WHERE user_id=? AND sub_account=? → ref，命中 asacca 前两列，索引正常；... ORDER BY id DESC LIMIT 20 → ref 命中 asacca（优化器未选 idx_user_sub_account_id），带 using_filesort；SUM 要聚合该用户全部历史流水（表 AUTO_INCREMENT 已 1362 万；平台内部账户 user 100-999 的单一 user_id+sub_account 组合可累积数十万行），且 after_amount/before_amount 不在索引内 → 每行回表，聚合行数大时 20s+。ORDER BY id DESC LIMIT 慢同理：asacca 不含 id 排序，回表后 filesort。ALTER TABLE hk8591.h8_finance_account_logs ADD INDEX idx_usa_amounts (user_id, sub_account, after_amount, before_amount);（低峰执行，线上先在从库验证）；idx_user_sub_account_id（该索引 (user_id, sub_account, id DESC) 可免 filesort），如 ORDER BY id DESC 已匹配则检查统计信息为何优化器弃用，必要时 ANALYZE TABLE；mysqldump 全表导出当日覆盖 8891 全部大表（Top10 中 9 条）与 100-slave 的 t591.t1_daily_report，单表最长 2030s。条数与历史常规量级一致（每大表 1 条），未触发深度分析。建议：备份窗口避开业务高峰，或改用 xtrabackup/快照方式减少 SQL 层全表扫描。
innodb_flush_log_at_trx_commit/sync_binlog；与备份错峰。h8_finance_account_logs SUM/分页：新增覆盖索引 (user_id, sub_account, after_amount, before_amount)；引导分页用 idx_user_sub_account_id；余额改汇总表/缓存。show engine innodb status 探针 254 次：降频或换 performance_schema 数据源。SELECT *，建议 xtrabackup 或延长备份间隔、限流（--single-transaction 已用前提下加 --max-allowed-packet 调优与带宽限速）。bica(buyer_id,...) range）：当前计划可接受，若量级上升可评估 (buyer_id, state, created_at) 复合索引消除过滤。es_slow_logs（staging, top=10）与 es_search（mysql_slow-*，size=5000，@timestamp ∈ [2026-11-01T00:00+08:00, 2026-11-02T00:00+08:00)，实际 1 页 2,028 条，search_after 未触发）。connect/describe_schema/explain，全程只读，分析后 disconnect。?，保留库表与 SQL 骨架；聚合在本地完成。max 耗时仅记录首见值缺失时未统计；commit/show/ping/rollback 为非 DML 语句，EXPLAIN 不适用（1064 属预期）。