技能介绍

先解决哪些问题

当数据库出现以下情况时，这套方法论能帮你定位瓶颈：

慢查询频发，接口响应时间波动大
连接池耗尽，服务启动后连接数持续上涨
读写分离后出现数据不一致
大表查询或更新越来越慢，索引加了也没效果
批量插入/更新操作耗时过长

核心能力与关键步骤

这套技能围绕执行计划分析、索引策略、连接管理、读写分离、分区治理五个核心展开，关键步骤如下：

执行计划优先：永远先跑EXPLAIN ANALYZE，从下往上读输出，重点看这些指标：

- 大表上的Seq Scan → 缺少有效索引
- 高行数的Nested Loop → 考虑换Hash/Merge Join
- 无索引的Sort → 给排序列加索引
- 预估行数与实际行数偏差大 → 统计信息过期，跑ANALYZE

索引策略选型：

- B-tree（默认）：适用于等值、范围、排序查询，复合索引要把等值列放前面
- 部分索引（PostgreSQL）：针对固定过滤条件的查询，索引体积更小
- GIN/GiST（PostgreSQL）：分别用于数组/JSONB/全文搜索、空间/范围类型
- 覆盖索引：支持索引仅扫描，减少回表

N+1查询检测：症状是1次查父表+N次查子表，开启查询日志，单个接口查询数超过10次就是危险信号
连接池配置：

- PostgreSQL：高并发/Serverless场景用PgBouncer事务模式，设置idle_in_transaction_session_timeout = '30s'，用pg_stat_activity监控
- MySQL：按内存设置max_connections（每连接约10MB），用ProxySQL做连接复用，用SHOW PROCESSLIST监控

读写分离与副本路由：所有SELECT走副本，写操作走主库，注意副本延迟（通常10-100ms），一致性敏感的读操作必须走主库，用连接级路由而非查询级
分区策略：表超过50-100GB或需要快速删旧数据时做分区，时序数据用范围分区，均匀分布用哈希分区
查询优化清单：包含10条可落地的检查项，比如替换SELECT *、批量插入（500-1000行/批）、用EXISTS替代COUNT(*) > 0、避免在WHERE子句的索引列上使用函数等
危险模式规避：列出了8类高危写法，比如未索引列上的LIKE '%term%'、深分页用OFFSET、无WHERE的UPDATE/DELETE等