企业官网建设流程全解析

1. 慢查询不是“等出来的”，而是“被误判的”

我接手一个线上报表服务的性能优化任务时，DBA 给我的第一份报告里写着：“慢查询集中在report_user_summary表，平均耗时 8.2 秒，建议加索引。”
我照着执行了——建了(tenant_id, status, created_at)复合索引，重启应用，监控面板上那条 SQL 的 P95 延迟从 8.2 秒掉到了 7.9 秒。
没变，几乎没变。

后来翻 DBeaver 的「活动会话」视图才发现：真正卡住的不是这条 SQL，而是它前面一条没进慢日志的UPDATE user_login_log SET last_active = NOW() WHERE user_id = ?—— 它在事务里锁住了user_login_log主键页，而报表查询恰好要 JOIN 这张表。
那条“慢查询”根本没执行完，它在等锁。

这就是我们今天要破的第一个认知误区：慢查询定位 ≠ 查慢日志里耗时最长的那几条 SQL。
DBeaver 不是日志阅读器，它是数据库的“实时听诊器”。它能让你在查询真正跑起来之前，就看到它卡在哪一层：是锁等待？是磁盘 IO 阻塞？还是执行计划突然退化成全表扫描？
而 AI 编程工具在这里的角色，从来不是代替你写 SQL，而是帮你把 DBeaver 里那些密密麻麻的指标、会话状态、执行计划节点，翻译成可操作的判断依据——比如自动比对两次 EXPLAIN 的rows_examined差异，或根据