1. 数据库性能排查的黄金五步法
当数据库响应变慢时，我通常会像老中医把脉一样，按照以下五个关键部位进行快速诊断。这套方法在MySQL、Oracle等关系型数据库中普遍适用，能解决80%以上的常见性能问题。
重要提示：所有诊断操作建议在业务低峰期进行，避免影响线上服务。生产环境操作前务必先验证SQL语句影响范围。
1.1 第一检查点：慢查询日志
慢查询日志是数据库自带的"黑匣子"，记录所有执行时间超过阈值的SQL语句。通过分析这些"问题SQL"，往往能直接定位性能瓶颈。
启用与配置方法（以MySQL为例）：
-- 查看当前慢查询设置 SHOW VARIABLES LIKE '%slow_query%'; -- 临时开启慢查询日志（重启失效） SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1; -- 阈值设为1秒 SET GLOBAL slow_query_log_file = '/var/log/mysql/mysql-slow.log'; -- 永久生效需修改my.cnf： [mysqld] slow_query_log = 1 slow_query_log_file = /var/log/mysql/mysql-slow.log long_query_time = 1 log_queries_not_using_indexes = 1 -- 记录未走索引的查询日志分析工具推荐：
mysqldumpslow：MySQL自带工具，提供基础统计pt-query-digest：Percona工具，支持多维分析- 阿里云DAS：可视化慢SQL分析平台
典型问题SQL特征：
- 全表扫描（rows_examined远大于rows_sent）
- 临时表使用（Using temporary）
- 文件排序（Using filesort）
- 嵌套循环连接（Using join buffer）
1.2 第二检查点：索引健康度
索引相当于数据库的"目录"，失效的索引会导致查询效率断崖式下降。我主要关注以下指标：
核心检查项：
-- 查看索引使用情况 SELECT * FROM sys.schema_unused_indexes; -- 查看索引统计信息 SHOW INDEX FROM 表名; -- 计算索引选择性（越高越好） SELECT COUNT(DISTINCT 列名)/COUNT(*) FROM 表名;索引失效的六大经典场景：
- 隐式类型转换（如VARCHAR字段用数字查询）
- 索引列使用函数（如WHERE DATE(create_time)=...）
- 前导模糊查询（LIKE '%关键字%'）
- 不符合最左前缀原则的联合索引
- 使用OR条件且未全覆盖索引
- 索引列参与计算（如WHERE id+1=100）
重建索引的正确姿势：
-- 在线重建（不锁表） ALTER TABLE 表名 ALGORITHM=INPLACE, LOCK=NONE, REBUILD PARTITION ALL; -- 针对InnoDB的优化操作 ANALYZE TABLE 表名; -- 更新统计信息 OPTIMIZE TABLE 表名; -- 重组物理存储1.3 第三检查点：连接池状态
连接数暴增是导致数据库雪崩的常见原因。我会重点检查：
关键指标监控：
-- 查看当前连接数 SHOW STATUS LIKE 'Threads_connected'; -- 查看连接来源分布 SELECT user,host,COUNT(*) FROM information_schema.processlist GROUP BY user,host; -- 查看活跃连接详情 SELECT * FROM information_schema.processlist WHERE COMMAND != 'Sleep';连接池优化建议：
- 设置合理的最大连接数（建议公式：CPU核心数*2 + 磁盘数）
- 配置连接超时（wait_timeout建议300-600秒）
- 使用连接池中间件（如HikariCP、Druid）
- 实现读写分离降低主库压力
突发连接数暴涨处理流程：
- 快速止血：
kill id终止异常连接 - 分析原因：检查应用连接泄漏或突发流量
- 长期方案：增加连接池监控告警
1.4 第四检查点：事务与锁争用
长事务和锁冲突会形成性能瓶颈链。诊断方法包括：
锁监控方法：
-- 查看当前锁等待 SELECT * FROM sys.innodb_lock_waits; -- 查看事务详情 SELECT * FROM information_schema.INNODB_TRX; -- 查看行锁情况 SHOW ENGINE INNODB STATUS;典型问题模式：
- 热点行更新导致的锁等待
- 未提交的长事务阻塞DDL操作
- 不合理的隔离级别设置
优化建议：
- 事务拆解：大事务改为小批量提交
- 锁升级避免：使用SELECT...FOR UPDATE SKIP LOCKED
- 死锁检测：设置innodb_deadlock_detect=ON
1.5 第五检查点：服务器资源瓶颈
最后要检查数据库所在服务器的"生理指标"：
关键资源检查命令：
# CPU使用率（重点关注%sys是否过高） top -H -p $(pgrep -d, mysqld) # 内存使用（关注swap是否被使用） free -h # 磁盘I/O（await>10ms说明有问题） iostat -dx 1 # 网络流量（关注重传率） sar -n DEV 1常见资源配置误区：
- 盲目调大innodb_buffer_pool_size导致OOM
- 未正确设置swappiness引发内存回收问题
- 机械硬盘部署未调整innodb_io_capacity
2. 实战案例：电商系统慢查询优化全记录
去年双十一期间，我们某个核心接口响应时间从200ms飙升到5秒。通过上述五步法，30分钟内定位并解决了问题。
2.1 问题现象
订单列表API响应变慢，伴随数据库CPU使用率达到90%
2.2 排查过程
- 通过慢查询日志发现一条统计SQL平均执行4.8秒
SELECT COUNT(*) FROM orders WHERE user_id=123 AND status IN (1,2,5) AND create_time > '2023-11-01';- 检查执行计划发现全表扫描
id: 1 select_type: SIMPLE table: orders partitions: NULL type: ALL # 全表扫描 possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 2,843,211 filtered: 1.23 Extra: Using where- 分析发现缺失复合索引，原有索引是单独的(user_id)和(create_time)
2.3 解决方案
- 紧急创建覆盖索引：
ALTER TABLE orders ADD INDEX idx_user_status_time(user_id, status, create_time);- 优化后执行计划：
id: 1 select_type: SIMPLE table: orders partitions: NULL type: range possible_keys: idx_user_status_time key: idx_user_status_time key_len: 9 ref: NULL rows: 127 filtered: 100.00 Extra: Using where; Using index- 最终效果：SQL执行时间降至23ms，CPU使用率回落至40%
3. 高级技巧：预防性维护体系
除了事后排查，我建立了以下预防机制：
3.1 自动化监控看板
- 慢查询TOP10（每分钟刷新）
- 连接数变化趋势
- 锁等待时间监控
- 资源使用率热力图
3.2 定期健康检查
每周自动执行以下检查：
- 索引使用率分析
- 表碎片率检查
- 统计信息时效性验证
- 备份恢复测试
3.3 性能测试规范
- 所有上线SQL必须通过EXPLAIN验证
- 重大变更前进行基准测试
- 建立SQL审核流程
这套方法让我管理的数据库集群连续三年保持99.99%的可用性，平均查询响应时间始终控制在200ms以内。最关键的是培养了对数据库性能问题的"直觉"——通过几个关键指标就能快速定位问题根源。
