MySQL5.7性能优化(二)概述

  数据库的性能取决于数据库级别的很多因素，例如表、查询和配置设置。这些软件的架构会在硬件层面影响CPU和I/O操作，你必须尽可能的最小化CPU和I/O的运作，并且使其效率越高越好。当你研究数据库性能的时候，你应该先学习软件方面的高级规则和指导方法，并且使用壁钟时间来对性能进行度量。当你成为专家的时候，你将了解更多关于系统内部发生的事情，并开始考虑诸如CPU周期和I/O操作之类的事情。
  大多数的用户希望通过现有的软件和硬件配置中来实现最佳的数据库性能。更高级的用户会寻求机会去通过改进Mysql本身来进行优化，或者开发他们自己的存储引擎和硬件系统来扩展MySQL的生态系统。

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

数据库层面的优化

  开发高速的数据库应用最重要因素是他的基本设计：

• 表的接口是否正确？特别是，列是否使用了正确的数据类型以及每个表是否具有适合于该数据类型的列?例如执行频繁更新的应用程序通常有多个表但列很少，而分析大量数据的应用程序通常只有几个表但列很多。
• 是否应用了适当的索引来提高查询的效率?
• 您是否为每个表使用了合适的存储引擎，并充分利用了所使用的每个存储引擎的优点和特性?特别是对于性能和可伸缩性来讲，事务存储引擎(如InnoDB)或非事务存储引擎(如MyISAM)的选择非常重要。

Node:
  InnoDB是新表默认的存储引擎，在实践中，InnoDB的高级性能特性意味着InnoDB表的性能通常优于更简单的MyISAM表，尤其是对于访问频率较高的数据库。

• 每个表都使用了适当的行样式么？行样式的选择依旧取决于表使用的存储引擎。特别是压缩表使用更少的磁盘空间，因此读写数据所需的磁盘I/O更少。所有类型的工作量的InnoDB表和只读MyISAM表都可以使用压缩。
• 应用是否使用了合适的锁策略？例如在适当的情况下通过允许共享访问让数据库操作可以并行，或者在适当的情况下请求独占访问，以便关键操作获得最高优先级。同样，存储引擎的选择也很重要。InnoDB存储引擎可以在不需要你参与的情况下处理大多数锁的问题，从而在数据库中实现更好的并发性，并减少了大量的测试和代码调优。
• 所有用于缓存的内存区域大小正确吗?即足以容纳频繁访问的数据，但又不至于由于缓存内存区过大导致物理内存过载和分页。要配置的主要内存区域是InnoDB缓冲池、MyISAM密钥缓存和MySQL查询缓存。

硬件层面的优化

  随着数据库的使用频率不断增大，任何的数据库应用程序都将面临着硬件性能的瓶颈。DBA必须评估是否有可能调优应用程序或重新配置服务器以避免这些瓶颈，或者是否需要更多的硬件资源。系统瓶颈通常来自以下来源:

• 磁盘检索。磁盘找到一段数据需要时间。现在的磁盘，这个时间一般小于10ms，所以理论上我们每秒可以做大约100次磁盘检索。这段时间随着新磁盘的使用而缓慢改进，并且很难针对单个表进行优化。优化寻道时间的方法是将数据分布到多个磁盘上。
• 磁盘读写。当磁盘在正确的位置时，我们需要对磁盘进行读写数据。现在的磁盘，一个磁盘至少提供10-20MB /s的吞吐量。因为可以从多个磁盘并行读取，所以这比检索更容易进行优化。
• CPU周期。当数据在主存中时，我们必须对其进行处理以获得结果。与内存量相比，CPU周期是大型表性能的最常见的限制因素。但是对于小表，速度通常没有什么问题。
• 内存带宽。当CPU需要超过CPU缓存容量的数据时，主内存带宽就会成为瓶颈。对于大多数系统来说，这是一个不常见的瓶颈，但是需要注意。

平衡性能和可移植性

  要在一个可移植MySQL程序中使用面向性能的SQL扩展，可以将MySQL特定的关键字封装在/*! * /语句的注释分隔符中。其他SQL服务器将会忽略注释的关键字。

回到综述页