数据库优化

慢查询从哪查起

线上接口偶发超时、报表扫全表拖垮 CPU，往往不是「加机器」能一劳永逸的。根因通常在执行计划：大表 Seq Scan、估计行数与实际严重偏离、或一次 HTTP 请求里打出十几条 SQL（典型 N+1）。在改 schema 或堆索引之前，需要一套可重复的读计划、验索引、控连接与读写路径的方法。

技能覆盖的核心能力

本技能把 PostgreSQL / MySQL 上常见的优化动作收成可执行的检查清单：

• EXPLAIN ANALYZE：从下往上读计划；关注 Seq Scan、Nested Loop 行数、无索引 Sort，以及 Rows estimated vs actual 偏差（提示跑 ANALYZE 刷新统计信息）。
• 索引策略：默认 B-tree 与复合索引列顺序（等值在前，范围/排序在后）；PostgreSQL 的 Partial / GIN / GiST 与覆盖索引（index-only scan）。
• N+1：父表 1 次查询 + 每个子项 1 次查询；开查询日志，单接口 SQL 数 >10 应警惕。
• 连接池：PgBouncer（transaction 模式）、idle_in_transaction_session_timeout；MySQL 的 max_connections 与 ProxySQL；用 pg_stat_activity / SHOW PROCESSLIST 观测。
• 只读副本：SELECT 走副本、写走主库；考虑复制延迟；读后写一致性读必须用主库；路由在连接级而非单条 SQL 级。
• 分区：Range（时序）、Hash（均匀分布）；表到 50–100GB 或需快速删历史数据时再考虑。

附带 Query Optimization Checklist（10 步）与 Dangerous Patterns（如 LIKE '%term%'、ORDER BY RANDOM()、深分页 OFFSET 应改 keyset/cursor）。

适用边界

技能是工程向备忘与决策树，不能替代对你库表、 workload 与 ORM 生成 SQL 的实测。副本延迟、事务锁、隐式类型转换导致索引失效等场景，仍需结合慢日志（如 PostgreSQL log_min_duration_statement）与业务 SLA 做权衡；未在资料中展开的其他引擎特性需自行查官方文档。