几个MySQL数据库优化建议

Posted 2021-05-01 智能MES

”导读：转载分享优化mysql的几点基础知识”

性能是我们衡量应用的一种方式，而应用性能的一项指标就是用户体验，也就是平时我们常说的：“用户需要等待超过合理的时间，才能获得他们想要的东西吗？”

    MySQL 有许多配置方法可以确保您的数据库能够快速地响应各种查询，同时仅对应用程序性能造成细微的下降。

以下就是能够帮助您优化 MySQL 数据库性能的 7 点必备技巧：

• 学习如何使用EXPLAIN

• 创建正确的索引

• 拒绝默认设置

• 将数据库载入内存中

• 使用SSD存储

• 横向扩展

• 追求可视性

学习如何使用 EXPLAIN

在您对数据库做任何设计决策时，有两个方面非常重要：

• 应用实体之间如何被映射到各个数据表（数据库模式架构）上。

• 应用程序如何获取（查询）到它们所需格式类型的数据。

    像许多 MySQL Workbench 之类的工具都可以将 EXPLAIN 的输出可视化地展示给您，不过您仍然需要了解与它相关的基本知识。

    EXPLAIN 命令的输出有两种不同的格式：老式的表格形式和较新的、能够提供更为细节化的、结构化的 JSON 文档。

    如下所示：

mysql> explain format=json select avg(k) from sbtest1 where id between 1000 and 2000 \G
*************************** 1. row ***************************
EXPLAIN: {
  “query_block”: {
    “select_id”: 1,
    “cost_info”: {
      “query_cost”: “762.40”
    },
    “table”: {
      “table_name”: “sbtest1”,
      “access_type”: “range”,
      “possible_keys”: [
        “PRIMARY”
      ],
      “key”: “PRIMARY”,
      “used_key_parts”: [
        “id”
      ],
      “key_length”: “4”,
      “rows_examined_per_scan”: 1874,
      “rows_produced_per_join”: 1874,
      “filtered”: “100.00”,
      “cost_info”: {
        “read_cost”: “387.60”,
        “eval_cost”: “374.80”,
        “prefix_cost”: “762.40”,
        “data_read_per_join”: “351K”
      },
      “used_columns”: [
        “id”,
        “k”
      ],
      “attached_condition”: “(`sbtest`.`sbtest1`.`id` between 1000 and 2000)”
    }
  }
}

    其中您需要重点查看的部分是：查询成本。查询成本是指基于查询执行的总体成本和许多不同的因素考虑，MySQL 判定一次查询所付出的花销。

    决定查询成本的一个首要因素是：查询是否正确地使用了各种索引。如果您没有使用索引进行查询，那么会被 EXPLAIN 命令所指出来，通常源于索引是如何在数据库中被创建的，以及查询本身是如何被设计的。

    这也正是为什么 EXPLAIN 值得去好好学习和使用的原因。

创建正确的索引

    在 MySQL 中，索引被用于加快对数据库的访问，并有助于遵循数据库的各种约束（例如 UNIQUE 和 FOREIGN KEY）。

    它们是数据位置的一种参考方法或映射，因此索引并不会更改数据库中的任何数据。它们只是指向数据存放的位置而已。

    因此，我们需要使用 EXPLAIN 来查找缺失的索引，并将其添加上去。

    需要注意的是：不要添加您所不需要的索引。

拒绝默认设置

    就像其他任何软件那样，MySQL 也能通过各种可配置的设置，来修改其行为并最终优化其性能。

    因此，通常您需要将 MySQL 配置为使用所有可用的内存资源，并且能允许您的应用程序所需的最大连接数。

    这里有三个有关 MySQL 性能优化的设置，值得您去仔细地配置：

innodb_buffer_pool_size

    数据和索引被用作缓存的缓冲池。当您的数据库服务器有着大量的系统内存时，可以用到该设置。

    如果您只运行 InnoDB 存储引擎，那么您通常可以分配 80％ 左右的内存给该缓冲池

    您在设置 InnoDB 缓冲池大小的时候，要确保其设置既不要过大，也不要频繁引起交换（swapping），因为这些绝对会降低您的数据库性能。有一个简单的检查方法就是在“Percona 监控和管理”。 

    如图所示，如果你看到有大于 1MB 每秒的持续交换活动的话，您就需要减少缓冲池的大小了，或者使用其他的内存。

    从 MySQL 5.7 开始，您可以动态地改变 InnoDB 缓冲池的大小，而不需要重新启动数据库服务器了。 

innodb_log_file_size

    这是指单个 InnoDB 日志文件的大小。默认情况下，InnoDB 使用两个值，这样您就可以通过将其增加一倍，来让 InnoDB 获得循环的重做日志空间。

    设置 innodb_log_file_size 的值是很值得推敲的：如果分配了较大的重做空间，那么对于写入密集型的工作负载来说性能会越好。

    您可以通过查看未实际使用的重做日志空间大小来判定。最简单的方法就是查看“Percona 监控和管理”的 InnoDB 指标仪表板。

    在下图中，InnoDB 的日志文件不够大，使用空间已经屡屡接近于可用的重做日志空间了，如红线所示：

    因此，您的日志文件应该至少比使用量大 20％，从而保持系统处于最佳的性能状态。

max_connections

    大型应用程序通常需要比默认数量多得多的连接。不同于其他的变量，如果您没能将该值设置正确，您就会碰到性能方面的问题。

    幸运的是，MySQL 能够在峰值操作时轻易地获悉所用到的连接数量。通常，您需要确保在应用程序所使用到的最大连接数和可用的最大连接数之间至少有 30％ 的差额。

    下图显示了一个健康的系统，它有着足够数量的可用额外连接。

    还有一点需要记住：如果您的应用程序所创建的连接数量过多，通常会导致数据库运行缓慢。

将数据库载入内存中

    近年来，出现了固态硬盘（SSD）方向上的转变。尽管固态硬盘比传统机械旋臂硬盘快得多，但是它们仍然敌不过将数据存在内存里。

    您并不需要将整个数据库载入内存以获得其性能优势，您只需要将最频繁访问的数据集放入其中便可。

    您可能已经看过一些文章，有介绍将数据库多少比例（如：10％ 到 33％）载入到内存里。

    而事实上并不存在着“一刀切”的规律，数据的访问量决定着载入内存所获得的最佳性能的提升程度。

使用 SSD 存储

    无论您的数据库是否已被载入内存，您都需要使用快速存储来处理写入操作，并且避免在数据库启动后（重启之后）出现性能问题。这里的快速存储就是指固态硬盘。

    现如今，固态硬盘的性能已经非常卓越、可靠且价格低廉了。 并非所有的固态硬盘都是同等生产的。对于数据库服务器来说，您应该选用那些专供服务器工作负载、且能精心呵护数据的 SSD。

横向扩展

    即使是性能最高的服务器也有局限性。业界一般用两种方法来进行扩展：纵向和横向。

    纵向扩展意味着购买更多的硬件。这样做不但成本昂贵，而且硬件折旧速度快。

    而横向扩展，则在处理负载方面有如下几点优势：

• 您可以从更小型、成本更低的系统中获益。

• 横向扩展使得系统的线性扩展更方便、更快捷。

• 由于数据库会横跨增长到多个物理机上，横向扩展在保护数据库的同时，消除了硬件单点故障。

    尽管横向扩展有着诸多优势，不过它还是具有一定的局限性。横向扩展需要数据复制，例如基本的 MySQL Replication 或是用于数据同步的 Percona XtraDB 群集。

    当然，过早地规划横向扩展，会增加分布式数据库的复杂性。最近发布的 MySQL 8 候选版本已声称自己能够在单一的系统上处理超过 200 万个简单查询。

追求可视性

    可视性是系统设计的最佳境界，MySQL 也不例外。

    一旦完成了 MySQL 环境的搭建、运行并调优，您千万不要认为已经万事大吉了。

    数据库环境既会受到来自系统更改或流量负荷的影响，也会遇到例如流量高峰、应用程序错误以及 MySQL 自身的各种问题。

常用的监测工具有：

• MySQL企业监控器（Enterprise Monitor）。

• Monyog。

• 具有免费与开源版本的 Percona 监控和管理（PMM）。

    这些工具在监控和故障排除方面提供了很好的操作可视性。