Skip to main content

1.优化磁盘I/O

本节介绍可以为数据库服务器投入更多、更快的存储硬件时配置存储设备的方法。 有关优化 InnoDB 配置以提高 I/O 性能的信息，请参阅“优化 InnoDB 磁盘 I/O”相关文章。

  • 磁盘查找是一个巨大的性能瓶颈。 当数据量开始增长到无法进行有效缓存时，这个问题就变得更加明显。 对于或多或少随机访问数据的大型数据库，可以确定至少需要一次磁盘寻道来读取数据，并需要几个磁盘寻道来写入数据。 为了最大限度地减少此问题，请使用寻道时间短的磁盘。
  • 通过将文件符号链接到不同磁盘或对磁盘进行条带化来增加可用磁盘轴的数量（从而减少寻道开销）：

    • 使用符号链接

      这意味着，对于 MyISAM 表，可以将索引文件和数据文件从数据目录中的常用位置符号链接到另一个磁盘（也可能是条带化的）。 假设磁盘不用于其他目的，这会缩短查找和读取时间。

      InnoDB 表不支持使用符号链接。 但是，可以将 InnoDB 数据和日志文件放置在不同的物理磁盘上。

    • 条带化

      条带化意味着有许多磁盘，并将第一个块放在第一个磁盘上，第二个块放在第二个磁盘上，第 N 个块放在 (N MOD number_of_disks) 磁盘上，依此类推。 这意味着如果正常数据大小小于条带大小（或完全对齐），将获得更好的性能。 条带化非常依赖于操作系统和条带大小，因此请使用不同的条带大小对应用程序进行基准测试。

      条带化的速度差异很大程度上取决于参数。 根据设置条带化参数和磁盘数量的方式，可能会得到几个数量级的差异。 必须选择针对随机访问或顺序访问进行优化。

  • 为了可靠性，可能希望使用 RAID 0+1（条带加镜像），但在这种情况下，需要 2 × N 个驱动器来保存 N 个驱动器的数据。 如果有足够的钱，这可能是最好的选择。 但是，可能还需要投资一些卷管理软件才能有效地处理它。
  • 一个好的选择是根据数据类型的重要性来改变 RAID 级别。 例如，可再生的半重要数据存储在RAID 0磁盘上，而真正重要的数据（例如主机信息和日志）存储在RAID 0+1或RAID N磁盘上。 如果有很多写入操作，RAID N 可能会出现问题，因为更新奇偶校验位需要时间。
  • 还可以设置数据库使用的文件系统的参数：
    • 如果不需要知道上次访问文件的时间（这在数据库服务器上并不是很有用），可以使用 -o noatime 选项挂载文件系统。 这会跳过对文件系统上 inode 中上次访问时间的更新，从而避免一些磁盘寻道。
    • 在许多操作系统上，可以通过使用 -o async 选项挂载文件系统来将其设置为异步更新。 如果的计算机相当稳定，这应该会给带来更好的性能，而不会牺牲太多的可靠性。 （此标志在 Linux 上默认打开。）

将 NFS 与 MySQL 结合使用​

在考虑是否将 NFS 与 MySQL 一起使用时应谨慎。 潜在问题因操作系统和 NFS 版本而异，包括以下内容：

  • 放置在 NFS 卷上的 MySQL 数据和日志文件被锁定且无法使用。 例如，当多个 MySQL 实例访问同一数据目录或 MySQL 因断电等原因而非正常关闭时，可能会出现锁定问题。 NFS 版本 4 通过引入咨询和基于租约的锁定来解决潜在的锁定问题。 但是，不建议在 MySQL 实例之间共享数据目录。
  • 由于接收到的消息无序或网络流量丢失而导致数据不一致。 要避免此问题，请使用带有硬挂载和 intr 挂载选项的 TCP。
  • 最大文件大小限制。 NFS 版本 2 客户端只能访问文件的最低 2GB（带符号的 32 位偏移量）。 NFS 版本 3 客户端支持更大的文件（最多 64 位偏移量）。 支持的最大文件大小还取决于 NFS 服务器的本地文件系统。

在专业 SAN 环境或其他存储系统中使用 NFS 往往比在此类环境之外使用 NFS 提供更高的可靠性。 然而，SAN 环境中的 NFS 可能比直接连接或总线连接的非旋转存储慢。

如果选择使用 NFS，建议使用 NFS 版本 4 或更高版本，就像在部署到生产环境之前彻底测试 NFS 设置一样。