8.1-优化概述

在数据库级别上，数据库性能取决于几个因素，如表，查询，和设置。这些软件构造最终影响硬件层面的CPU和I/O操作，而这两者是你必须要尽可能降低和使其高效的。在研究数据库性能时，你开始要学习软件层次的高级规则和指导原则，使用时间来衡量性能。当你成为专家时，你会学及内部发生的事情，开始考虑CPU循环和I/O操作。

通常，用户会基于现有的软件和硬件设置来追求数据库的最大性能。高级用户可能会优化MySQL软件本身的性能，或者是开发自己的存储引擎和硬件设置来扩展MySQL生态系统。

数据库层面的优化。
硬件层面的优化。
可移植性和性能的平衡。

数据库层面的优化 #

对一个数据库应用运行速度影响最大是是它的基础设计：

表结构是否正确？相关的数据列是否有正确的数据类型？根据负载不同，每张表是否有适合的列数？例如，进行频繁更新的应用通常列数更少，而用于分析大量数据的应用通常表少，但是每张表的列数更多(?)。
是否建有正确的索引，使得查询更高效？
每张表是否使用了合适的存储引擎，是否充分利用了相关存储引擎的优势？尤其是，对于事务型存储引擎，比如InnoDB，或非事务型存储引擎，比如MyISAM 的选择对于性能和可一致性来说非常重要。
```
  InnoDB是新表的默认存储引擎。实际上，InnoDB的一些高级特色使InnoDB通常比简单的MyISAM表表现更好，尤其是在一个操作频繁的数据库中。
```
每张表是否有合适的数据格式（row format）？这个选择取决于这张表使用的存储引擎。特别指出，压缩表使用更少的磁盘空间，所以在读写数据时会产生更少的磁盘I/O消耗。使用InnoDB时，压缩适合各种工作负载，但使用MyISAM时，只适合于只读表。
应用是否使用和合适的锁策略？例如，允许共享访问使得数据库操作可以并发执行，允许请求排它锁使得关键操作可以得到高优先级执行。再次说明，存储引擎的选择非常重要。使用InnoDB存储引擎，通常大部分锁问题不需要你处理，数据库的并发性能更好，减少了测试和代码调优的工作量。
是否所有的内存区域都用于缓存？意思是说，内存是否足够容纳经常访问的数据，而不会因物理内存不足导致使用虚拟内存。大部分内存通常被设置成InnoDB的buffer pool和MyISAM的key 缓存。

硬件层面的优化 #

受限于硬件，随着数据库中操作越来越频繁，任何一个数据库都会最终达到瓶颈。DBA需要平通时可以通过调节应用，或修改服务器设置来避免这种瓶颈，或者是否需要更多的硬件资源。系统瓶颈通常来自以下方面：

磁盘扫描。磁盘查找数据需要花费时间。现在的磁盘，平均查找时间通常低于10ms，所以理论上我们没秒可以查找100次。使用新磁盘时，这个时间值提升很少。对于单张表来说，很难优化访问时间。优化查找时间的方式是将数据分布在多个磁盘上。
读取磁盘和写入磁盘。当确定磁盘位置后，我们就要读取或写入数据。对于现代磁盘来说，一个磁盘的吞吐量至少可以达到10-20MB/s。这通常比查找更容易优化，因为你可以并行读取多个磁盘。
CPU循环。数据在内存中时，我们需要对其进行处理来得到我们要的结果。内存有限，而表很大，是常见的限制因素。但是对于小表来说，通常不是问题。
内存带宽。当CPU缓存无法容纳CPU需要的数据时，主内存就成为了瓶颈。这个瓶颈不常见，但的确有可能。

可移植性和性能的平衡 #

要在可移植的MySQL应用中使用基于性能的SQL扩展，你可以将MySQL关键词包裹在/*! */中。其它数据库服务器会忽略评论中的关键词。要了解更多关于评论的信息，见9.7 “Comments”。