8.1 优化概述

8.1 优化概述

数据库性能由多种因素决定，在数据库层面的因素有表结构，查询语句，和数据库配置等，这些因素会影响到 CPU 执行周期，I/O 等硬件因素，一般来说一个好的查询语句应该通过减少 CPU 执行周期和 I/O 操作来获得尽
可能好的性能。对于新手来说处理数据库优化的问题，首先应该从数据库软件高级规则和指南入手，这时候只需要通过计时来衡量数据库的性能；如果你已经是个数据库优化方面的高手，你需要深入的了解数据库的运行原理，然后开始通过 CPU 执行周期和 I/O 操作的次数来衡量数据库性能

一般用户希望在已有的软硬件前提下获得最好的数据库性能，高级一点的用户会尝试优化 MySQL 本身，包括但不限于开发自己的存储引擎，开发专属硬件设备来丰富 MySQL 生态。

数据库层级的优化

数据库的基础设计是决定数据库能跑多快的最重要因素：

• 是否使用了合适的表结构。每一列是否使用了正确的数据类型，每张表使用设计了合适的列数。例如，经常执行更新的应用对应列数少的多张表，经常进行大数据量分析的应用对应列数多的少量表

• 是否正确使用了索引来加速查询？

• 每张表是否使用了正确的存储引擎，以及是否正确利用了每个存储引擎的优点？例如，有事务处理的存储引擎（如 InnoDB）和 无事务处理的存储引擎（如 MyISAM）之间的选择对于性能和可扩展性来说是非常重要的。

Note
InnoDB 是默认的存储引擎， 实践中发现， 得益于 InnoDB 的高级性能特性， InnoDB 表在性能上表现的比简单的 MyISAM 表更好，对于频繁读写的数据库优势会更加明显

• 每张表是否使用了正确的行格式？这个选择也有表的存储引擎决定。特别的，压缩表使用更少的磁盘空间，在读写数据的使用使用更少的 I/O 次数。所有类型的 InnoDB 表和只读类型的 MyISAM 表都可以使用压缩功能。

• 应用是否使用了正确的加锁策略？例如在情况允许的前提下使用共享读写，能够提高数据库的并发性能，在适当的使用使用排外锁读写数据，使得重要的操作有更高的优先级。重申一次，选择合适的存储引擎是十分重要的， InnoDB 引擎可以自动处理大多数的加锁情况，在减少代码中手动加锁操作的同时获取更好的数据库并发性能。

• 各个存储区域是否正确设置了缓存大小？也就是说缓存足够大以放置经常获取的数据；也不能设置过大至超过物理内存，否则将会导致系统换页。可配置存储区域主要是 InnoDB 的缓冲池和 MyISAM 的键缓存。

硬件层级的优化

任何一个数据库应用伴随着越来越频繁的读写最终都会达到硬件的极限。DBA 需要评估是否可以通过调整应用和重新设置服务器来避免性能瓶颈，还是需要增加更多的硬件资源。系统瓶颈一般来源于以下方面：

• 磁盘寻道。磁盘查找一个数据需要花费时间，对于现代磁盘来说，磁盘寻道时间通常少于 10ms，所以理论上一秒钟可以进行 10 次寻道。现在来说寻道速度的提升是非常缓慢的，所以很难通过提升寻道速度来优化一张表，为了减少寻道时间可以将数据分开存储在不同的磁盘。

• 磁盘读写。现代的磁盘寻道结束，读取或写入数据的速度至少在 10-20MB/s，由于可以对多张磁盘并行读写，这个速度比磁盘寻道速度容易提升。

• CPU 执行周期。当数据已经从磁盘读取到主存的时候，需要进行数据的处理和输出结果。当表数据量过大而内存不足的时候，就会造成性能瓶颈。但对于小表来说一般不会有速度上的问题。

• 内存带宽。当 CPU 需要比 CPU 缓存更大的数据量，主存的贷带宽就会成为瓶颈。但对于大多数系统来说这不是一个常见的瓶颈处，只需要了解这个瓶颈就好。

平衡便携和性能

在一个便携式的 MySQL 应用中使用优化性能的扩展时，可以用 /*！*/ 注释语法将包含 MySQL 特定的关键字的语句注释掉。其他的 SQL 服务器会无视注释掉的语句。