数据库性能取决于数据库级别的几个因素,例如表,查询和配置设置。 这些软件构造导致在硬件级别执行CPU和I / O操作,必须将这些操作最小化并使其尽可能高效。
数据库优化级别分为如下:
- 数据库层面的优化
- 硬件层面的优化
- 平衡可移植性和性能
数据库层面的优化
要使数据库应用程序快速运行,最重要的因素是其基本设计:
- 表格的结构是否正确?特别是,这些列是否具有正确的数据类型,并且每个表都具有适合于该工作类型的列吗?例如,执行频繁更新的应用程序通常具有许多表而具有很少的列,而分析大量数据的应用程序通常具有很少的表而具有很多列。
- 是否创建了正确的索引以提高查询效率?
- 是否为每个表使用了适当的存储引擎,并利用了所使用的每个存储引擎的优势和功能? 特别是,对于性能和可伸缩性而言,选择事务存储引擎(例如InnoDB)或非事务存储引擎(例如MyISAM)可能非常重要
InnoDB是新表的默认存储引擎。 实际上,先进的InnoDB性能功能意味着InnoDB表通常优于简单的MyISAM表,尤其是对于繁忙的数据库 - 每个表都使用适当的行格式吗?该选择还取决于表使用的存储引擎。 特别是,压缩表使用较少的磁盘空间,因此需要较少的磁盘I/O来读取和写入数据。压缩可用于带有InnoDB表的所有类型的工作负载以及只读的MyISAM表
- 应用程序是否使用适当的锁定策略?例如,通过在可能的情况下允许共享访问,以便数据库操作可以同时运行,并在适当的时候请求独占访问,以使关键操作获得最高优先级。同样,存储引擎的选择很重要。 InnoDB存储引擎无需认为参与即可处理大多数锁定问题,从而可以更好地并发数据库并减少代码的试验和调整量
- 用于缓存的所有内存区域大小是否正确? 也就是说,足够大以容纳经常访问的数据,但又不能太大以至于它们会使物理内存过载并导致分页。要配置的主要内存区域是InnoDB缓冲池和MyISAM密钥缓存
硬件层面的优化
随着数据库变得越来越繁忙,任何数据库应用程序最终都会达到硬件极限。 DBA必须评估是否有可能调整应用程序或重新配置服务器以避免这些瓶颈,或者是否需要更多的硬件资源。 系统瓶颈通常来自以下来源:
- 磁盘寻址。磁盘查找数据需要花费时间。对于现代磁盘,此操作的平均时间通常小于10毫秒,因此理论上我们可以执行100次搜索。 这段时间随着新磁盘的使用而缓慢改善,并且很难为单个表进行优化。优化寻道时间的方法是将数据分发到多个磁盘上
- 磁盘读写。当磁盘位于正确的位置时,我们需要读取或写入数据。 对于现代磁盘,一个磁盘至少可提供10–20MB/s的吞吐量。与查找相比,优化起来更容易,因为您可以从多个磁盘并行读取
- CPU周期。当数据位于主存储器中时,我们必须对其进行处理以获得结果。与内存量相比,拥有较大的表是最常见的限制因素,但是对于下的table,速度通常不是问题。
- 内存带宽。当CPU需要的数据超出CPU缓存的容量时,主内存带宽将成为瓶颈。对于大多数系统来说,这是一个不常见的瓶颈,但是要意识到这一点
平衡可移植性和性能
要在可移植的MySQL程序中使用面向性能的SQL扩展,可以在/*!中的语句中包装特定于MySQL的关键字*/注释定界符。 其他SQL Server忽略注释的关键字。