数据库性能调优方案1.docx

PAGE 16 数据库性能调优方案  作为综合性多业务的“互联网+生活服务”平台，美团点评对数据库的稳定运行有较高的要求，小概率的性能抖动（包括慢SQL）都会造成一定的可用性损失。本文将从过去几年遇到的一些性能问题中，挑选了一个较为棘手的案例，探究端到端数据库性能问题的解决思路，为DBA同学在解决类似问题时提供一种参考。 问题描述 在一段时间内不断有开发同学反馈，线上应用程序获取数据超时，通过CAT监控系统发现这些应用的SQL 99line都比较高，这在一定程度上影响了对应业务的QoS，比如达不到99.99%的业务可用性(超时被定义为不可用)。这些问题出现在很多业务场景中，是一个普遍性问题。 通过CAT监控系统、SQL样本、慢查询系统等进一步了解，发现这类SQL有如下特征: 基本上都是以主键或唯一键为条件的简单查询，查询后的结果集及扫描的行数都比较小； 查询的表的数据总量也很小，最小的表甚至只有几千行； 时间达到了几百ms，甚至1s； 数据库的slow log里没有记录这类SQL。 下图为CAT相关监控数据的样本，以xxx-service这个service为例： 99line的监控数据，有很多SQL的返回时间超过100ms以上。 SQL的绝对数量在2016年9月6日当天为 ：3788。 具体到某个SQL，甚至达到了929ms。 FB_Coach的表结构如下： 可看到最多