1. 数据库性能排查的五个黄金检查点当数据库响应变慢时我通常会第一时间检查这五个关键位置。这套方法经过多年实战验证能快速定位80%以上的性能瓶颈。不同于教科书式的理论分析这里分享的都是可直接落地的实操经验。为什么是这五个点因为它们覆盖了从硬件资源到SQL优化的完整链条连接池压力反映并发处理能力索引状态决定查询效率事务隔离影响并发性能硬件资源是底层保障而慢查询日志直接暴露问题SQL。下面我会用MySQL和Oracle的混合案例说明原理通用包含大量常规文档不会提及的排查技巧。2. 第一检查点数据库连接池2.1 连接数监控与瓶颈识别通过SHOW STATUS LIKE Threads_connectedMySQL或SELECT count(*) FROM v$sessionOracle查看当前连接数。关键指标是连接数利用率当前连接数/最大连接数当超过70%就需要警惕。典型问题场景连接泄漏应用未正确关闭连接导致连接数持续增长连接池配置过小突发流量时无法满足需求长事务占用连接连接被长时间占用无法释放提示突然的连接数飙升往往伴随应用发布或配置变更要结合变更记录排查2.2 连接池优化实战调整max_connections参数不是万能药。我通常这样做先用SHOW PROCESSLIST查看活跃连接状态对Sleep状态的连接设置合理的wait_timeout建议300-600秒应用层使用连接池时注意验证连接有效性配置避坑经验不要盲目增大max_connections会导致上下文切换开销剧增Java应用推荐使用HikariCP而非DBCP后者有已知的性能缺陷ORM框架如Hibernate要配置合理的连接释放策略3. 第二检查点索引健康度3.1 索引失效的六大元凶通过EXPLAIN分析慢查询时要特别关注这些索引问题隐式类型转换如字符串字段用数字查询前导模糊查询LIKE %xxx无法使用索引函数操作字段WHERE YEAR(create_time)2023不符合最左前缀联合索引(a,b,c)但条件只有b1索引选择性差性别字段建索引基本无效统计信息过期表数据变化大但未重新分析3.2 索引优化进阶技巧重建索引的正确姿势-- MySQL示例 ALTER TABLE orders FORCE INDEX(primary); ANALYZE TABLE orders;多维度索引策略时间范围查询(status, create_time)联合索引分类检索(category_id, is_deleted)过滤大部分数据覆盖索引SELECT a,b FROM tbl WHERE c1可建(c,a,b)注意Oracle的位图索引在OLAP场景很高效但OLTP中慎用4. 第三检查点事务与锁争用4.1 锁等待检测方法MySQL查看锁等待SELECT * FROM performance_schema.events_waits_current WHERE EVENT_NAME LIKE wait/io/table/sql/handler;Oracle更直观SELECT * FROM v$lock WHERE block1;4.2 事务优化方案降低隔离级别从SERIALIZABLE降级到READ COMMITTED可大幅提升并发事务拆解技巧大事务拆为小批次提交非核心操作移到事务外查询操作使用READ ONLY事务避坑案例 某电商系统在秒杀时出现大量锁超时最终发现是SELECT...FOR UPDATE范围过大改为精确主键锁定后QPS提升15倍。5. 第四检查点硬件资源瓶颈5.1 快速诊断四件套CPUvmstat 1看us和sy是否持续70%内存free -h观察buff/cache使用率磁盘IOiostat -x 1看%util和await网络sar -n DEV 1检查吞吐量和错误包5.2 配置调优重点InnoDB专属优化innodb_buffer_pool_size 总内存的70-80% innodb_io_capacity SSD建议设4000 innodb_flush_neighbors 0 # SSD必关Oracle内存管理ALTER SYSTEM SET sga_target4G SCOPEBOTH; ALTER SYSTEM SET pga_aggregate_target2G SCOPEBOTH;6. 第五检查点慢查询日志分析6.1 日志配置要点MySQL开启慢查询slow_query_log 1 long_query_time 1 # 超过1秒记录 log_queries_not_using_indexes 1Oracle使用AWR报告SELECT * FROM TABLE(DBMS_WORKLOAD_REPOSITORY.awr_report_html( l_dbid (SELECT dbid FROM v$database), l_inst_num 1, l_bid NULL, l_eid NULL));6.2 日志分析实战使用pt-query-digest工具生成报告pt-query-digest /var/log/mysql-slow.log slow_report.txt重点分析执行次数Top10的查询单次耗时最长的查询全表扫描的查询临时表使用情况文件排序操作7. 性能问题速查手册7.1 症状与解决方案对照表症状表现可能原因排查工具解决方案CPU持续高但QPS低锁等待或低效SQLSHOW PROCESSLIST优化事务隔离级别连接数突然飙升连接泄漏或突发流量网络流量监控增加连接池限制单IP连接查询时快时慢统计信息不准EXPLAIN变体分析手动更新统计信息批量操作特别慢自动提交模式事务日志分析改用批量提交简单查询突然变慢索引失效执行计划对比重建索引优化查询条件7.2 必备监控指标清单连接池活跃连接数/空闲连接数/等待线程数缓存命中率InnoDB buffer pool hit rate 95%锁等待row_lock_waits 0需要关注临时表created_tmp_disk_tables占比应5%线程状态大量Copying to tmp table需要优化这套检查流程在我经历的生产事故中屡试不爽。最近一次金融系统性能危机中通过检查连接池配置和事务隔离级别仅用2小时就将TPS从50提升到1200。关键是要建立系统化的检查习惯而不是头痛医头脚痛医脚。
原理与实战解析)
