1、概述：
数据库性能依赖表、查询以及配置设置等数据库层面要素；这些软件层面的构造会影响在硬件层面的CPU和IO操作，而这些都需要你尽可能降低并使之高效率运行的元素。传统用户一般通过软硬件配置来获得数据库最好的性能，而高端用户则通过改善软件本身或者通过开发自己的存储引擎和硬件装置来扩展MYSQL生态系统。
2、如何优化
1）数据库层面的优化：使数据库变得更块最主要的元素是它的基础设计。
★ 合适的
表结构？特别是列设置了
正确的数据类型，每个表有适当的列？例如：应该程序不应该频繁更新大量的表中少许的列，而应该是少量表中大量的列。
★
是否设置了
正确的索引
使查询更加高效？
★
每个表使用了
合适的存储引擎
，并获得了该存储引擎的优势和特性的优势。特别的，事务存储引擎innoDB和非事务存储引擎MyISAM的选择可能对性能和可扩展性很重要。
★
每个表使用
合适的行格式
；这个也依赖该表使用的存储引擎。尤其是该表压缩表使用更少的磁盘空间以及使用更小的磁盘IO去读取和写入数据。压缩对于所有工作负载的InnoDB表和只读的MyISAM表是有效的。
★
应用程序采用来
合适的锁策略
。如可能的时候通过允许共享访问使数据库操作可以并发运行，而且专用请求访问也可以在可能的时候获取更高的优先级。还有存储引擎的选择很重要，InnoDB可以不用你参与的情况下解决绝大部分锁问题，允许更好的并发并减少很多实现和代码调整。
★
所有内存区域使用的
缓存大小
是否合适？足够大到保持住频繁的数据访问，而不是足够大以至于超过物理内存并引起分页；主内存区域的配置包括InnoDB缓存池、MyISAM键缓存和MYSQL查询缓存。
2）硬件层面的优化：数据库应用最终会越来越多的触碰到硬件的限制，DBA需要评估是否调整应用程序或重新配置服务器以避免系统瓶颈
，更或者需要更多的硬件资源
★
磁盘寻道（DISK SEEK）：从磁盘获取一段数据的带来的时间。现代的磁盘一般获取时间一般低于10ms，这样理论上100次寻道就是1s，但是对于单表，这样的通过磁盘寻道去优化时间是很难的，一般优化寻道时间的方式是通过把数据分别存储到多个磁盘上。
★
磁盘读写：当磁盘寻道到正确的位置，我们需要读取和写入数据。现代磁盘传输数据至少10~20M/s的吞吐量。这是比磁盘寻道更容易的方法，因为你可以并发读多个磁盘。
★
CPU周期（CPU cycles）：数据在主内存时，我们必须处理它获取结果。内存中的大表的比较是一个较普遍的限制，但是对于小表，速度不是问题
★
内存带宽：CPU需要更多的数据命中CPU缓存，这时主内存带宽变成了一个瓶颈；这个在大多数系统是不普遍的，但是要注意。