本文根据阿里云资深DBA专家罗龙九在首届阿里巴巴在线峰会的《云数据库十大经典案例分析》的分享整理而成。罗龙九以MySQL数据库为例，分析了自RDS成立至今，用户在使用RDS过程中最常见的问题，包括：索引、SQL优化、锁、延迟、参数优化、连接数、CPU、Iops、磁盘、内存等。罗龙九通过对十大经典案例的总结，还原问题原貌，给出分析问题的思路，旨在帮助用户在使用RDS的路上少一些弯路，多一些从容。
直播视频
（点击图片查看视频）
幻灯片下载：点此进入
以下为整理内容。
案例一：索引
今天之所以将索引放在第一位进行分享，是因为索引的问题出现频率是最高的。常见的索引问题包括：无索引、隐式转换两类。其中隐式转换是由SQL传入的值和表结构定义的数据类型不一致引起；或者是表字段定义的collation不一致导致多表join的时候出现隐式转换。无索引的情况会导致全表扫描；隐式转换会导致索引无法正常使用。
在使用索引时，我们可以通过explain（extended）查看SQL的执行计划，判断是否使用了索引以及发生了隐式转换。由于常见的隐式转换是由字段数据类型以及collation定义不当导致，因此我们在设计开发阶段，要避免数据库字段定义，避免出现隐式转换。此外，由于MySQL不支持函数索引，在开发时要避免在查询条件加入函数，例如date(gmt_create)。最后，所有上线的SQL都要经过严格的审核，创建合适的索引。
案例二：SQL优化
SQL优化是很多使用者都需要面对的问题。我们在不断地优化、调试过程中总结了三类SQL优化的最佳实践，分别是分页优化、子查询优化、查询需要的字段。
分页优化
这条语句是普通的Limit M、N的翻页写法，在越往后翻页的过程中速度越慢，这是由于MySQL会读取表M+N条数据，M越大，性能越差。
我们通过采用高效的Limit写法，可以将上述语句改写成：
select t1.* from buyer t1,
(select id from buyer sellerid=100 limit 100000，5000) t2
where t1.id=t2.id; 从而避免分页查询给数据库带来性能影响。需要注意一点是，这里需要在t表的sellerid字段上创建索引，id为表的主键。
子查询优化
子查询在MySQL5.1、5.5版本中都存在较大的风险。这是一段典型子查询SQL代码：
SELECT first_name
FROM employees
WHERE emp_no IN
(SELECT emp_no FROM salaries_2000 WHERE salary = 5000); 由于MySQL的处理逻辑是遍历employees表中的每一条记录，代入到子查询中去 。所以当外层employees表越大时，循环次数也随之增多，从而导致数据库性能的下降。
这是我们改写子查询之后的SQL代码：
SELECT first_name
FROM employees emp,
(SELECT emp_no FROM salaries_2000 WHERE salary = 5000) sal
WHERE emp.emp_no = sal.emp_no;
首先将子查询的结果放到临时表内，再去和employees表做关联。此外，使用者也可以选择使用Mysql 5.6的版本，避免麻烦的子查询改写。
查询需要的字段
在访问数据库时，应该尽量避免使用SELECT *查询所有字段数据，只查询需要的字段数据。
案例三：锁
在使用数据库时，每个人或多或少都会碰到锁的问题。在设计开发阶段，我们需要注意这三点问题：一是避免使用myisam存储引擎，改用innodb引擎；二是注意避免大事务，这是因为长事务导致事务在数据库中的运行时间加长，造成锁等待；三是选择将数据库升级到支持online ddl的MySQL 5.6版本。
在管理运维阶段，我们可以从四点出发搞定锁的问题：
- 在业务低峰期执行上述操作，比如创建索引，添加字段；
- 在结构变更前，观察数据库中是否存在长SQL，大事务；
- 结构变更期间，监控数据库的线程状态是否存在lock wait；
- RDS支持在DDL变更中加入 wait timeout。
案例四：延迟
由于数据库架构大多是主备的方式，延迟便成了一个常见的问题。产生延迟的原因有很多，例如在只读实例架构中，主备节点间MySQL原生复制实现数据同步方式会天然导致延迟的产生。此外，create index、repair等常见DDL操作、大事务、MDL锁以及资源问题都会导致延迟的出现。
处理延迟问题，需要具有清晰的排除思路：一看资源是否达到瓶颈；二看线程状态是否有锁；三判断是否存在大事务。同时我们还可以通过使用innodb存储引擎、将大事务拆分为小事务、DDL变更期间观察是否有大查询等具体最佳实践降低延迟。
案例五：参数优化
我们曾经遇到这样一个案例，某金融客户在将本地的业务系统迁移上云后，在最高配置的RDS上运行时间明显要比线下自建数据库运行时间慢1倍，进而导致客户系统出现割接延期的风险。对于这类案例的分析，根据以往的经验，可以从以下三点出发：
- 首先查看数据库是否是跨平台迁移（PG->MySQL、ORALCE->MySQL）；
- 其次查看是否是跨版本升级(MySQL:5.1->5.5、5.5->5.6)，不同的版本之间是有差异的；
- 如果上述两点都不存在，则需要查看具体的执行计划、优化器、参数配置、硬件配置。
如果SQL从云下迁移到云上或者从一个版本迁移到另一个版本的过程中出现性能问题时，要保持清晰的排查思路：从SQL执行计划到数据库版本和优化器规则，再到参数（包括Query_cache_size、Temp_table_size）配置和硬件配置等一一进行排查。曾经看到这样一个案例，一个用户使用默认的mysql配置跑线上应用，db所在的主机的内存有500G，但是分配给MySQL的内存确是默认的128M，导致了整个系统的性能下降。
案例六：CPU 100%最佳实践
导致CPU 100%的三大因素分别是：慢SQL、锁和资源。对于慢SQL问题：我们可以通过优化索引或者通过避免子查询、隐式转换以及进行分页改写等措施从根上解决该问题。对于锁等待问题：可以通过设计开发和管理运维优化锁等待。对于资源问题：可以通过参数优化、弹性升级、读写分离、数据库拆分等方式优化。
案例七：Conm 100%
导致Conm 100%的三大因素分别是慢SQL、锁、配置。对于慢SQL问题：解决方案类似于处理CPU 100%，同样是通过优化索引或者通过避免子查询、隐式转换以及进行分页改写等措施从根上解决该问题。对于锁等待问题：同样可以通过设计开发和管理运维优化锁等待。对于配置问题：我们需要合理规划数据库上的连接数的使用，避免客户端连接池参数配置超过实例最大连接数的情况出现。此外，还可以通过弹性升级RDS的规格配置来满足客户端需要的连接数。
案例八：Iops 100%
Iops 100%也是一个很常见的问题。导致Iops 100%的原因也可以分为慢SQL问题、DDL、配置问题三类。对于慢SQL问题：解决方案同样类似于处理CPU 100%问题，通过优化索引或者通过避免子查询、隐式转换以及进行分页改写等措施从根上解决该问题。对于DDL问题：一定要避免并发进行create index、optimze table、alter table add column等操作；同时这些操作最好在业务低峰期进行。对于配置问题：可以通过弹性升级RDS的规格配置解决。
案例九：disk 100%
磁盘空间由数据文件、日志文件和临时文件组成。对于数据空间问题：由于数据文件的索引和数据是放在一起的，当对表删除数据后可以采用optimize table收缩表空间，同时删除不必要的索引；对于写多读少的应用，可以使用tokudb压缩引擎进行表压缩。对于日志空间问题：首先我们需要减少大字段的使用；其次可以使用truncate替代delete from。对于临时空间问题：一是可以适当地调大sort_buffer_size；二是可以创建合适索引避免排序。
案例十：mem 100%
当内存使用率达到100%时，操作系统会kill掉MySQL进程，从而导致业务的中断。因此，我们需要明确地了解数据库的内存使用详情。数据库内存主要由Buffer pool size 、Dictionary memory、Thread cost memory三部分组成。对于Buffer pool size问题：首先，我们可以通过创建合适的索引，避免大量的数据扫描；其次，我们需要去除不必要的索引，降低内存的消耗。对于Thread cost memory问题：一方面，我们可以通过创建合适的索引避免排序；另一方面，在查询数据时，我们只查询应用所需的数据，避免所有数据的查询。对于Dictionary memory问题：当表被访问打开后其元数据信息是存储在Dictionary memory之中的，过度的分表会导致内存的大量占用，因此分表时要注意把握分寸，不多过度分表，曾经看到一个数据库中创建了十几万张表。
关于分享嘉宾：
罗龙九，阿里云资深DBA专家，有着丰厚的DBA经验，经历阿里历年双11考验，负责阿里云RDS线上稳定以及专家服务团队，积累了6年对阿里云数据库用户的运维、调优、诊断等丰富的经验。
