数据库优化需要考虑哪些方面？

一个正常运行的系统突然出现性能问题，该从什么地方开始调查？

首先，试着获取用户的反馈信息，什么时候系统开始变慢了？哪些功能出现了卡顿？性能问题出现之前系统作了哪些变更？用户的反馈可以帮助我们快速缩小问题排查的范围，重点关注性能下降前的系统变更。

从数据库层面，MySQL数据库的优化可以从以下几个方面考虑：

• 表的设计是否合理？字段类型定义是否正确？字段的大小是否合适？合适的大小是指可以满足业务需求前提下最小的。字段长度小意味着更少的磁盘占用、更少的I/O、更小的内存占用及更小的索引。每一项优势都会为系统提速。这些都是在设计表时容易忽略的内容。在设计表时可以反复运行procedure analyse 来让系统为字段的选型提供一些建议。

• 在模式设计时，在LOTP（Online Transaction Processing 联机事务处理）系统中，表中的字段应尽可能少，将经常处理的“热”数据放在一起，过大的表可以将不常用的字段分离出去，然后用数字ID在查询时进行连接。

• 表的索引建立的是否合适？索引可以为查询提速，但同时会降低更新、插入、删除的速度。对于小的表，全表扫描可能是更合适的读取方式。对于过大的表，索引带来的性能提升也不明显，可以试着采用分区等技术为查询加速。MySQL的物理存储特点决定了主键扫描是最快的访问方式，同时主键索引也会被附加至所有的二级索引后面，有一个短小并且高效的主键是提升表查询效率的关键（推荐使用auto_increment列作为主键）。

• 表的存储引擎选择是否正确？对于大部分场景，InnoDB可能是最合适的存储引擎，同时也是MySQL的默认存储引擎。了解InnoDB存储引擎原理和特点可以提升优化能力。

• 文件存储格式选择是否正确？MySQL默认的行存储格式是Compact，但大部分情况并不是最优的选择，可以根据表中数据特点为表选择合适的存储格式。例如：在表中存在大量重复，compressed格式可能是更好的选择。对于text、BLOB等文本数据，dynamic格式可能更适合。

• 数据库的配置是否合理？数据缓冲、日志缓冲、表缓存等设置是否合理，过小的缓冲区可能会导致数据被频繁读入内存和刷回磁盘，在条件允许的情况下，尽量给数据缓冲留下充足的空间（缓存的数据越多，MySQL表现的就越像一个内存数据库）。

• 数据库I/O分配，建议将数据表和日志的分布在不同的物理磁盘驱动上，事务在提交时会刷日志到磁盘，在繁忙的系统可能与数据I/O产生争用。

• 应用的SQL是否高效？大部分SQL效率低下的原因都是未正确使用索引或逻辑不够好，应用可能只需要少量的数据，但是SQL却检索了大量的数据最后又将大部分丢弃掉。SQL的优化可以借助MySQL的慢查询日志或性能模式（performance schema）中的统计信息来分析应用SQL的效率。

因为系统的配置变更频率很小，大部分的性能优化都是由SQL执行效率产生的，通过了解数据库、SQL、索引、执行计划，可以分析SQL从解析到返回数据过程中做了哪些操作，找出“成本”最高的操作，逐步优化。