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 表名;

索引失效的六大经典场景：

1. 隐式类型转换（如VARCHAR字段用数字查询）
2. 索引列使用函数（如WHERE DATE(create_time)=...）
3. 前导模糊查询（LIKE '%关键字%'）
4. 不符合最左前缀原则的联合索引
5. 使用OR条件且未全覆盖索引
6. 索引列参与计算（如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';

连接池优化建议：

1. 设置合理的最大连接数（建议公式：CPU核心数*2 + 磁盘数）
2. 配置连接超时（wait_timeout建议300-600秒）
3. 使用连接池中间件（如HikariCP、Druid）
4. 实现读写分离降低主库压力

突发连接数暴涨处理流程：

1. 快速止血：kill id终止异常连接
2. 分析原因：检查应用连接泄漏或突发流量
3. 长期方案：增加连接池监控告警

1.4 第四检查点：事务与锁争用

长事务和锁冲突会形成性能瓶颈链。诊断方法包括：

锁监控方法：

-- 查看当前锁等待 SELECT * FROM sys.innodb_lock_waits; -- 查看事务详情 SELECT * FROM information_schema.INNODB_TRX; -- 查看行锁情况 SHOW ENGINE INNODB STATUS;

典型问题模式：

• 热点行更新导致的锁等待
• 未提交的长事务阻塞DDL操作
• 不合理的隔离级别设置

优化建议：

1. 事务拆解：大事务改为小批量提交
2. 锁升级避免：使用SELECT...FOR UPDATE SKIP LOCKED
3. 死锁检测：设置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

常见资源配置误区：

1. 盲目调大innodb_buffer_pool_size导致OOM
2. 未正确设置swappiness引发内存回收问题
3. 机械硬盘部署未调整innodb_io_capacity

2. 实战案例：电商系统慢查询优化全记录

去年双十一期间，我们某个核心接口响应时间从200ms飙升到5秒。通过上述五步法，30分钟内定位并解决了问题。

2.1 问题现象

订单列表API响应变慢，伴随数据库CPU使用率达到90%

2.2 排查过程

1. 通过慢查询日志发现一条统计SQL平均执行4.8秒

SELECT COUNT(*) FROM orders WHERE user_id=123 AND status IN (1,2,5) AND create_time > '2023-11-01';

2. 检查执行计划发现全表扫描

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

3. 分析发现缺失复合索引，原有索引是单独的(user_id)和(create_time)

2.3 解决方案

1. 紧急创建覆盖索引：

ALTER TABLE orders ADD INDEX idx_user_status_time(user_id, status, create_time);

2. 优化后执行计划：

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

3. 最终效果：SQL执行时间降至23ms，CPU使用率回落至40%

3. 高级技巧：预防性维护体系

除了事后排查，我建立了以下预防机制：

3.1 自动化监控看板

• 慢查询TOP10（每分钟刷新）
• 连接数变化趋势
• 锁等待时间监控
• 资源使用率热力图

3.2 定期健康检查

每周自动执行以下检查：

1. 索引使用率分析
2. 表碎片率检查
3. 统计信息时效性验证
4. 备份恢复测试

3.3 性能测试规范

1. 所有上线SQL必须通过EXPLAIN验证
2. 重大变更前进行基准测试
3. 建立SQL审核流程

这套方法让我管理的数据库集群连续三年保持99.99%的可用性，平均查询响应时间始终控制在200ms以内。最关键的是培养了对数据库性能问题的"直觉"——通过几个关键指标就能快速定位问题根源。