统计范围：2026-09-28 00:00:00 ~ 23:59:59（Asia/Shanghai，ES @timestamp 按 UTC 换算）
环境：staging | 数据源：MCPes_slow_logs/es_search（索引mysql_slow-*）| 全程只读
| 指标 | 数值 |
|---|---|
| 慢查询总条数 | 1,237 |
| 累计耗时 | 4.16 小时 |
| 单条平均 / 最大耗时 | 12.1s / 1,502.7s（t8891.t_item_modi_histories backup） |
| backup 用户（mysqldump）条数 / 累计 | 411 条 / 3.30h（占 79% 耗时） |
| 非 backup 条数 / 累计 | 826 条 / 0.90h |
| 慢查询最多实例 | LAN_addcn_84（8891 master，268 条）、LAN_addcn_27_3307（hk8591，221 条） |
| 主要来源用户 | backup 411、jmysql（监控）317、8591 应用 173、sonic 89、a591 51 |
| # | 耗时 | 用户 | 库.表 | rows_sent | 慢因类型 |
|---|---|---|---|---|---|
| 1 | 1502.7s | backup | t8891.t_item_modi_histories | 5,693,964 | 大结果集传输（mysqldump 全表导出，EXPLAIN type=ALL 预估 502 万行 / 14G） |
| 2 | 1135.6s | backup | t8891.t_sele_item_infos | 3,290,762 | 大结果集传输（全表导出，301 万行 / 20G） |
| 3 | 467.3s | backup | t8891.yahoo_car_details | 16,681 | 大结果集传输（行数少但含 raw_html 等超宽字段，18M/scan） |
| 4 | 365.0s | backup | t8891.t_subscription_push | 39,105,741 | 大结果集传输（3,953 万行 / 33G，全表仅 4 列） |
| 5 | 300.3s | backup | t8891.t_sele_item_photos | 22,929,970 | 大结果集传输（2,180 万行 / 80G 宽行） |
| 6 | 294.8s | backup | t591.t1_daily_report | 29,838,336 | 大结果集传输（2,885 万行 / 7G） |
| 7 | 290.8s | sonic | （事务 commit，无表） | 0 | 其他：commit 落盘耗时（大事务/IO 争用，Lock_time≈0） |
| 8 | 238.1s | backup | anylink_corp.access_audit | 56,491,318 | 大结果集传输（5,212 万行 / 65G，仅 PRIMARY KEY 无二级索引） |
| 9 | 229.4s | backup | anylink.access_audit | 49,054,753 | 大结果集传输（4,539 万行 / 56G） |
| 10 | 223.8s | backup | hk8591.h8_orders | 39,105,741* | 大结果集传输（全表导出，249 万行，行极宽） |
\* #10 rows_sent 与 #4 相同系慢日志字段采集所致，以 rows_examined≈249 万为准。
Top10 结论：9/10 为 mysqldump 全表导出（SELECT /*!40001 SQL_NO_CACHE */ *），EXPLAIN 全部为 type=ALL 全表扫描——这是备份的固有行为，加索引无意义；#7 为 sonic 事务 commit 耗时。Top10 无一为业务 SQL 缺索引问题。
| # | 条数 | 平均 | 最大 | 累计 | 用户 | 实例 | 指纹 |
|---|---|---|---|---|---|---|---|
| 1 | 255 | 1.47s | 2.8s | 6.2min | jmysql | 8.27/8.37/8.40/8.46 多实例 | SHOW ENGINE INNODB STATUS; |
| 2 | 92 | 5.76s | 290.8s | 8.8min | eagle, sonic | 8.37, 8.84 | commit; |
| 3 | 48 | 2.26s | 13.9s | 1.8min | 8591 | 8.27:3307 | select id,buyer_id,completed_at from h8_orders where buyer_id IN (?) and state=? order by created_at asc |
| 4 | 33 | 1.32s | 1.9s | 0.7min | bee, jumper_dev | 8.27, 8.37 | COMMIT; |
| 5 | 33 | 1.22s | 2.3s | 0.7min | 8591 | 8.27:3307 | insert into h8_telescope_entries (...) values (...多行...) |
| # | 条数 | 平均 | 最大 | 累计 | 用户 | 指纹 |
|---|---|---|---|---|---|---|
| 1 | 1 | 1502.7s | 1502.7s | 25.0min | backup | SELECT /*!? SQL_NO_CACHE */ * FROM t8891.t_item_modi_histories |
| 2 | 1 | 1135.6s | 1135.6s | 18.9min | backup | SELECT ... FROM t8891.t_sele_item_infos |
| 3 | 92 | 5.76s | 290.8s | 8.8min | eagle, sonic | commit; |
| 4 | 16 | 30.33s | 70.9s | 8.1min | 8591 | SELECT sum(after_amount-before_amount) FROM h8_finance_account_logs where user_id=? and sub_account=? |
| 5 | 1 | 467.3s | 467.3s | 7.8min | backup | SELECT ... FROM t8891.yahoo_car_details |
backup 模式标注：mysqldump 全表导出类指纹（user=backup / databasus_backup，共 411 条 / 3.3h）已在表中加粗标注，不触发深度分析；昨日条数与常规备份规模一致（每表 1 条），未见环比翻倍异常。
触发规则：非 backup 模式条数>100 或 累计>30min 必须深入。昨日仅 SHOW ENGINE INNODB STATUS（255 条 >100）硬性触发；另对最伤业务的 h8_finance_account_logs（avg 30s）、h8_orders buyer_id IN（48 条）、house_repost（19 条 avg 1.1s）、h8_telescope_entries delete（6 条 avg 41s）一并做了完整 describe_schema + EXPLAIN 深挖。
SHOW ENGINE INNODB STATUS;（255 条，硬性触发）SELECT sum(after_amount - before_amount) FROM hk8591.h8_finance_account_logs WHERE user_id=? AND sub_account=?（16 条，avg 30.3s，max 70.9s）asacca(user_id, sub_account, course, created_at)、idx_user_sub_account_id(user_id, sub_account, id DESC)。type=ref，选了 idx_user_sub_account_id 但 key_len=8 只用到 user_id 前缀，sub_account 靠 ICP 过滤（filtered 10%），单 user 预估扫 21,126 行、回表取 before/after_amount。ALTER TABLE hk8591.h8_finance_account_logs ADD INDEX idx_user_sub_amounts (user_id, sub_account, before_amount, after_amount);
可消除回表并让 SUM 直接在索引上完成；业务侧建议把"余额"做成 h8_finance_accounts 余额列（记账时原子更新），避免每次全量 SUM 流水。
h8_orders buyer_id IN (...) AND state=? ORDER BY created_at（48 条，avg 2.3s）bica(buyer_id, created_at)、sieca(state, is_exclusive, canceled_at)、gist(goods_id, state) 等 14 个。sieca(state) 前缀 + using_filesort，buyer_id 作 attached_condition 过滤——用错索引：state 选择性低，bica(buyer_id, created_at) 才是正解（buyer_id 等值 + created_at 排序，免 filesort）。(buyer_id, state, created_at)，或 SQL 里 FORCE INDEX (bica)；state 过滤在回表后做，通常远快于按 state 扫全量再 filesort。SELECT * FROM t591.house_repost WHERE ispay=? AND status=? AND type!=? ORDER BY rectime ASCtype(type, post_id)。EXPLAIN：type=ALL 全表扫 195,963 行 + filesort，filtered 0.98%。ALTER TABLE t591.house_repost ADD INDEX idx_pay_status_rectime (status, ispay, rectime);
同时避免 SELECT *（该表含 log 文本列）。
created_at。EXPLAIN（等价 SELECT）：type=ALL 全扫 99,819 行。ALTER TABLE hk8591.h8_telescope_entries ADD INDEX idx_created_at (created_at);，并考虑 staging 关闭 Telescope 或缩短保留期（telescope:prune 定时小批量删）。sum(json_unquote(json_extract(properties,'$.card_commission_charges')))gist(goods_id, state)，rows≈1，计划本身健康。慢主要发生在数据分布不同/IO 争用时段；建议将高频佣金字段从 JSON 提升为生成列并建索引：ALTER TABLE h8_orders ADD COLUMN card_commission_charges DECIMAL(12,2) GENERATED ALWAYS AS (CAST(json_unquote(json_extract(properties,'$."card_commission_charges"')) AS DECIMAL(12,2))) STORED, ADD INDEX idx_ccc (seller_id, goods_id, state, completed_at);--single-transaction --sleep/ionice），长期改 XtraBackup 物理备份或直接用从库（8.59/8.52/8.46）导出，避免在 8.84/8.51 主库压 IO。(user_id, sub_account, before_amount, after_amount)；架构上改余额列，消除高频全量 SUM。(buyer_id, state, created_at) 或 FORCE INDEX(bica)，消除 filesort。(status, ispay, rectime) 复合索引，去 SELECT *。created_at 索引 + 缩短 Telescope 保留期。created_at 分区或定期归档，减小备份体量。innodb_flush_log_at_trx_commit/sync_binlog 在 staging 可放宽），避开备份窗口。es_slow_logs(top=10, env=staging) + es_search(索引 mysql_slow-*，全量 1,237 条，search_after 分页)；深度分析走 MCP connect → describe_schema → explain（只读账号 jmysql）。.agents/scripts/slow_report_20260928_gather.py / slow_report_20260928_deep.py；中间数据 outputs/slow_data_20260928.json、outputs/deep_20260928.json。