数据库性能调优方案.pdfVIP

数据库性能调优方案 1 作为综合性多业务的“互联网 + 生活服务”平台，美团点评对数据库的稳定运行有较高的要求，小概 率的性能抖动 （包括慢 SQL ）都会造成一定的可用性损失。 本文将从过去几年遇到的一些性能问题中， 挑选了一个较为棘手的案例，探究端到端数据库性能问题的解决思路，为 DBA 同学在解决类似问题 时提供一种参考。 问题描述 在一段时间内不断有开发同学反馈，线上应用程序获取数据超时，通过 CAT 监控系统发现这些应用 的 SQL 99line 都比较高，这在一定程度上影响了对应业务的 QoS ，比如达不到 99.99% 的业务可用 性 (超时被定义为不可用 ) 。这些问题出现在很多业务场景中，是一个普遍性问题。 通过 CAT 监控系统、 SQL 样本、慢查询系统等进一步了解，发现这类 SQL 有如下特征 : 基本上都是以主键或唯一键为条件的简单查询，查询后的结果集及扫描的行数都比较小； 查询的表的数据总量也很小，最小的表甚至只有几千行； 时间达到了几百 ms ，甚至 1s； 数据库的 slow log 里没有记录这类 SQL 。 下图为 CAT 相关监控数据的样本，以 xxx-service 这个 service 为例： 99line 的监控数据，有很多 SQL 的返回时间超过 100ms 以上。 2 SQL 的绝对数量在 2016 年 9 月 6 日当天为 ：3788 。 具体到某个 SQL ，甚至达到了 929ms 。 3 FB_Coach 的表结构如下： 可看到最多 641 条记录，还有联合索引。 概要分析 要想定位到原因，必须通过排除法找到该 SQL 到底慢在哪个阶段，这样才能缩小范围。接下来我们 来分析慢 SQL 的花费时间组成。从下图可看出，时间主要由 3 部分组成： 4 App Server ：发出 SQL 请求的时间，接收返回结果的时间 网络： SQL 请求包及查询结果在网络上花费的时间 MySQL Server ：发出 SQL 到查询结果整个过程花费的时间 我们可以通过抓包工具获取每个阶段花费的时间，从而定位到底慢在哪个阶段。 问题解决思路迭代 思路 1 ：确认哪个过程花费的时间最多 5 方法： 分别在 APP Server 与 MySQL Server 部署 TcpDump 抓包工具， 得到数据包在 4 个监测点的 “到达时间”。为了方便，把如下 4 个 Wireshark 分析结果（对 TcpDump 抓取日志分析）按 4 个 方位标注： APP Server 发出 SQL （左上） MySQL Server 收到 SQL （右上） MySQL Server 将查询发出（右下） APP Server 收到查询结果（左下） 从 数 据 可 以 准 确 的 看 出 时 间 主 要 花 费 在 MySQL 内 部 ， 具 体 时 间 为