database Roadmap
数据库 / 缓存专题
数据库 / 缓存排障专题：聚合 MySQL Too many connections、lock wait timeout、慢查询、Redis OOM 与 big key、连接池打满和缓存穿透击穿等常见问题的完整排障路径与命令模板。
数据库问题先查连接数、慢查询、锁、内存和上游应用连接池配置，很多"数据库慢"其实是应用侧未释放连接或慢请求堆积，不要只调大 max_connections 或 maxmemory 参数掩盖根因。
Troubleshooting Path
推荐排障路线图
- 01
先看连接和资源指标
确认连接数、CPU、内存、磁盘和网络是否达到瓶颈。
- 02
再定位慢查询、锁和大 key
MySQL 看 processlist/innodb status，Redis 看 memory/bigkeys/TTL。
- 03
继续检查应用连接池
很多连接堆积来自应用池配置、慢请求和未释放连接，而不是数据库参数太小。
- 04
最后做参数调整和容量规划
调整 max_connections、maxmemory 或淘汰策略前，先确认业务影响和回滚方式。
Common Issues
高频问题入口
Before You Change
执行前检查
- 不要只调大连接数掩盖慢查询
- 修改数据库参数前记录原值
- Redis 清理 key 前确认业务归属
- 生产库执行 kill query 前确认影响范围
Start Here
优先阅读
CI 缓存失效排查方法
CI 缓存不命中、每次构建都从零安装依赖时，先对比 restore/save 步骤打印的 cache key 是否变化，再检查缓存路径配置、runner OS 前缀和 gh cache list 中的实际条目，常见根因是 key 把易变内容算入或 restore-keys 顺序不对。
排障Redis 连接不上怎么排查
Redis 客户端报 Could not connect: Connection refused 或 NOAUTH Authentication required 时，先确认 6379 端口是否监听、redis.conf 的 bind 是否限制为 127.0.0.1、protected-mode 是否阻止远程访问，再核对 requirepass 密码和 Docker 端口映射与容器网络。
排障CI 构建内存不足与进程被杀排查
CI 构建时出现 JavaScript heap out of memory、Killed 或 exit code 137，先区分 Node 堆内存不足与系统 OOM，再调整 NODE_OPTIONS=--max-old-space-size、Runner 内存和并发 job，覆盖 GitHub Actions、GitLab CI 和自建 Runner 场景。
排障Linux OOM Killer 与内存不足排查
Linux 进程被 OOM Killer 杀、容器状态 OOMKilled 或 dmesg 出现 Out of memory: Killed process 时，用 dmesg -T 与 journalctl -k 查历史内核日志确认时间和被杀进程，区分宿主机 OOM 与容器 cgroup 限制，再看进程 RSS 增长趋势排查泄漏。
Cheatsheets
相关速查表
MySQL 常用命令速查表
MySQL 日常运维命令一页速查：连接与用户管理、库表操作、查询与索引、进程与锁排查、备份恢复和主从状态检查等 30+ 高频操作，含关键参数说明与典型排障场景示例。
速查PostgreSQL 常用命令速查表
PostgreSQL 日常运维命令一页速查：连接与角色管理、库表操作、查询分析、锁与事务排查、备份恢复和复制状态检查等 30+ 高频操作，含关键参数说明与典型排障场景示例。
速查Redis 常用命令速查表
Redis 日常运维命令一页速查：连接管理、字符串与数据结构操作、键空间扫描、持久化与内存排查、发布订阅和集群状态检查等 30+ 高频操作，含关键参数说明与典型排障场景示例。
Latest Updates
最近更新
All Runbooks
全部相关内容
CI 构建内存不足与进程被杀排查
CI 构建时出现 JavaScript heap out of memory、Killed 或 exit code 137，先区分 Node 堆内存不足与系统 OOM，再调整 NODE_OPTIONS=--max-old-space-size、Runner 内存和并发 job，覆盖 GitHub Actions、GitLab CI 和自建 Runner 场景。
排障CI 缓存失效排查方法
CI 缓存不命中、每次构建都从零安装依赖时，先对比 restore/save 步骤打印的 cache key 是否变化，再检查缓存路径配置、runner OS 前缀和 gh cache list 中的实际条目，常见根因是 key 把易变内容算入或 restore-keys 顺序不对。
排障Linux OOM Killer 与内存不足排查
Linux 进程被 OOM Killer 杀、容器状态 OOMKilled 或 dmesg 出现 Out of memory: Killed process 时，用 dmesg -T 与 journalctl -k 查历史内核日志确认时间和被杀进程，区分宿主机 OOM 与容器 cgroup 限制，再看进程 RSS 增长趋势排查泄漏。
排障MySQL Lock wait timeout exceeded 排查
MySQL 报 Lock wait timeout exceeded; try restarting transaction 时，用 SHOW ENGINE INNODB STATUS 看 LATEST DETECTED DEADLOCK，通过 information_schema.innodb_trx 与 data_lock_waits 找 blocking 事务，短期 kill 会话，长期缩短事务并补索引避免大范围锁。
排障MySQL Too many connections 排查与缓解
MySQL 报 Too many connections、连接数达到 max_connections 时，SHOW PROCESSLIST 按用户/IP/数据库/状态聚合连接，识别大量 Sleep 或长时间 Sending data 的会话，检查应用连接池 max pool size 是否超过数据库承载，而不是盲目调大 max_connections。
排障PostgreSQL connection refused 排查方法
psql 连接 PostgreSQL 报 could not connect to server: Connection refused 时，先确认服务是否 running、5432 是否监听、postgresql.conf 的 listen_addresses 是否绑定到目标 IP，再逐层排查防火墙、安全组和 Docker 端口映射，pg_hba.conf 只影响后续认证。
排障Redis 连接不上怎么排查
Redis 客户端报 Could not connect: Connection refused 或 NOAUTH Authentication required 时，先确认 6379 端口是否监听、redis.conf 的 bind 是否限制为 127.0.0.1、protected-mode 是否阻止远程访问，再核对 requirepass 密码和 Docker 端口映射与容器网络。
排障Redis 内存占用过高与淘汰策略排查
Redis 内存持续上涨、报 OOM command not allowed when used memory > 'maxmemory' 或 evicted_keys 飙升时，先用 INFO memory 看 used_memory/maxmemory，CONFIG GET maxmemory-policy 确认策略是否 noeviction，再用 --bigkeys 找大 key 并检查 TTL 是否缺失。
命令MySQL 查看锁等待和事务命令
MySQL 排查锁等待和事务阻塞的常用命令，SHOW FULL PROCESSLIST 看当前活跃会话与状态，SHOW ENGINE INNODB STATUS 读 LATEST DETECTED DEADLOCK，information_schema.innodb_trx 和 performance_schema.data_lock_waits 找 blocking 事务，必要时 KILL <thread_id>。
命令Node/Nuxt 构建内存排查命令
Node/Nuxt/Next 构建报 JavaScript heap out of memory 或 exit code 137 时排查内存的常用命令，用 NODE_OPTIONS=--max-old-space-size=4096 扩大 V8 堆，du 查看 .nuxt/.output/.next 构建产物体积，free -h 与 dmesg 判断系统 OOM。
命令ps 查看进程和资源占用命令
Linux ps 查看进程静态快照的常用命令，ps aux --sort=-%cpu/-%mem 按 CPU 或内存排序找可疑进程，ps -ef | grep 按名称过滤，ps -o pid,ppid,stat,etime,cmd 查父子进程和状态，pstree -ap 展示进程树，动态观测配合 top/pidstat。