每个 MySQL 支持的应用程序都可以从经过微调的数据库服务器中受益。 多年来，Liquid Web Heroic 支持团队遇到了许多情况，一些细微的调整使网站和应用程序性能发生了天翻地覆的变化。 在本系列文章中，我们概述了一些对性能影响最大的更常见的建议。
预检
本文适用于大多数基于 Linux 的 MySQL VPS 服务器。 这包括但不限于传统专用和 Cloud 运行各种常见 Linux 发行版的 VPS 服务器。 本文可与以下 Liquid Web 系统类型一起使用：
- 核心管理的 CentOS 6x/7x
- 核心管理的 Ubuntu 14.04/16.04
- 完全托管的 CentOS 6/7 cPanel
- 完全托管的 CentOS 7 Plesk Onyx 17
- 自我管理的 Linux 服务器
注意选择退出直接支持的自我管理系统可以利用此处讨论的技术，但是，Liquid Web Heroic 支持团队无法对这些服务器类型提供直接帮助。
本系列文章假定您熟悉以下基本系统管理概念：
- 标准的 SSH 连接和基本导航 Linux命令行shell环境.
- 打开、编辑和保存文件 维姆 或选择的系统编辑器。
- MySQL交互模式 和通用的 MySQL 查询语法。
什么是 MySQL 优化？
术语 MySQL 优化没有明确定义的定义。 它可能意味着不同的人、管理员、团体或公司。 对于 MySQL 优化系列文章，我们将 MySQL 优化定义为： MySQL 或 MariaDB 服务器的配置，已配置为避免本系列文章中讨论的常见瓶颈。
什么是瓶颈？
与汽水瓶上的瓶颈非常相似，作为技术术语的瓶颈是应用程序或服务器配置中的一个点，少量流量或数据可以毫无问题地通过。 但是，较大量的同类型流量或数据受到阻碍或阻塞，无法按原样成功运行。 请参阅以下内容 example 配置瓶颈：
在这个 example，服务器能够同时处理 10 个连接。 但是，配置只接受 5 个连接。 只要一次有 5 个或更少的连接，这个问题就不会出现。 但是，当流量增加到 10 个连接时，由于服务器配置中未使用的资源，其中一半开始失败。 上面的例子说明了瓶颈的形状，它是从它的名字中得到的，而优化的配置可以纠正瓶颈。
我什么时候应该优化我的 MySQL 数据库？
理想情况下，数据库性能调整应该定期进行，并且在生产力受到影响之前进行。 最佳做法是每周或每月对数据库性能进行审计，以防止问题对应用程序产生不利影响。 性能问题最明显的症状是：
- 查询在 MySQL 进程表中堆积起来并且永远不会完成。
- 使用数据库的应用程序或网站变得迟缓。
- 连接超时错误，尤其是在高峰时段。
虽然在繁忙的系统上同时运行多个并发查询是正常的，但当这些查询需要很长时间才能定期完成时，就会出现问题。 尽管特定阈值因系统和应用程序而异，但超过几秒的平均查询时间将表现为附加网站和应用程序的速度减慢。 这些减速有时会从很小的时候开始，并且在大量流量激增达到特定瓶颈之前被忽视。
识别性能问题
了解如何检查 MySQL 进程表对于诊断遇到的特定瓶颈至关重要。 根据您的特定服务器和偏好，有多种方法可以查看进程表。 为简洁起见，本系列将重点介绍最常用的方法 安全外壳 (SSH) 访问：
方法 1. 使用 MySQL 进程表
使用 ‘mysql管理员‘带有标志的命令行工具’进程列表‘ 或者 ‘过程‘ 简称。 （添加标志’统计数据‘ 或者 ‘统计‘ 简而言之，将显示自 MySQL 上次重新启动以来查询的运行统计信息。）
命令：
mysqladmin proc stat输出：
+-------+------+-----------+-----------+---------+------+-------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+-------+------+-----------+-----------+---------+------+-------+--------------------+----------+
| 77255 | root | localhost | employees | Query | 150 | | call While_Loop2() | 0.000 |
| 77285 | root | localhost | | Query | 0 | init | show processlist | 0.000 |
+-------+------+-----------+-----------+---------+------+-------+--------------------+----------+
Uptime: 861755 Threads: 2 Questions: 20961045 Slow queries: 0 Opens: 2976 Flush tables: 1 Open tables: 1011 Queries per second avg: 24.323笔记：临： 在 shell 接口上使用，这使得管道输出到其他脚本和工具变得容易。骗局： 进程表的信息列总是被截断，因此不提供对较长查询的完整查询
方法二：使用 MySQL 进程表
跑过 ‘显示进程列表；‘ 从 MySQL 交互模式提示中查询。 （添加 ‘满的‘ 命令的修饰符禁用截断 信息 柱子。 在查看长查询时这是必要的。）
命令：
show processlist;输出：
MariaDB [(none)]> show full processlist;
+-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+
| 77006 | root | localhost | employees | Query | 151 | NULL | call While_Loop2() | 0.000 |
| 77021 | root | localhost | NULL | Query | 0 | init | show full processlist | 0.000 |
+-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+临： 使用 full 修饰符可以查看更长查询的完整查询。骗局： MySQL 交互模式无法访问 shell 界面中可用的脚本和工具.
使用慢查询日志
MySQL 中另一个有价值的工具是包含的慢查询日志记录功能。 此功能是定期查找长时间运行查询的首选方法。 有几个指令可用于调整此功能。 但是，最常用的设置是：
查看表
| 慢查询日志 | 启用/禁用慢查询日志 |
| 慢查询日志文件 | 慢查询日志文件的名称和路径 |
| long_query_time | 以秒/微秒为单位定义慢查询的时间 |
这些指令设置在 [mysqld] MySQL 配置文件的部分位于 /etc/my.cnf 并且需要重启 MySQL 服务才能生效。 见 example 下面的格式：
警告：慢查询日志文件存在较大的磁盘空间问题，需要持续关注，直到禁用慢查询日志功能。 请记住，long_query_time 指令越低，慢查询日志填满磁盘分区的速度就越快
[mysqld]
log-error=/var/lib/mysql/mysql.err
innodb_file_per_table=1
default-storage-engine=innodb
innodb_buffer_pool_size=128M
innodb_log_file_size=128M
max_connections=300
key_buffer_size = 8M
slow_query_log=1
slow_query_log_file=/var/lib/mysql/slowquery.log
long_query_time=5启用慢查询日志后，您将需要定期跟进它以查看需要调整以获得更好性能的不规则查询。 要分析慢查询日志文件，您可以直接对其进行解析以查看其内容。 以下 example 显示运行时间超过配置的 5 秒的示例查询的统计信息：
警告启用慢查询日志功能会影响性能。 这是由于分析每个查询需要额外的例程以及将必要的查询写入日志文件所需的 I/O。 因此，在生产系统上禁用慢查询日志被认为是最佳实践。 当主动寻找可能影响应用程序或网站的麻烦查询时，慢查询日志应仅在特定持续时间内保持启用状态。
# Time: 180717 0:23:28
# User@Host: root[root] @ localhost []
# Thread_id: 32 Schema: employees QC_hit: No
# Query_time: 627.163085 Lock_time: 0.000021 Rows_sent: 0 Rows_examined: 0
# Rows_affected: 0
use employees;
SET timestamp=1531801408;
call While_Loop2();或者，您可以使用 mysqldumpslow 命令行工具，它解析慢查询日志文件并将类似查询组合在一起，但数字和字符串数据的值除外：
~ $ mysqldumpslow -a /var/lib/mysql/slowquery.log
Reading mysql slow query log from /var/lib/mysql/slowquery.log
Count: 2 Time=316.67s (633s) Lock=0.00s (0s) Rows_sent=0.5 (1), Rows_examined=0.0 (0), Rows_affected=0.0 (0), root[root]@localhost
call While_Loop2()（有关使用信息，请访问此处的 MySQL 文档 – mysqldumpslow — 总结慢查询日志文件)
结论
至此结束了我们的数据库优化系列的第一部分，并为我们提供了一个坚实的基础来参考基准。 尽管数据库问题可能很复杂，但我们的系列将分解这些概念，以提供通过数据库转换、表转换和索引来优化数据库的方法。
我们如何提供帮助？
我们以成为 Hosting™ 中最有帮助的人而自豪！
我们的支持团队由经验丰富的 Linux 技术人员和才华横溢的系统管理员组成，他们对多种网络托管技术有着深入的了解，尤其是本文中讨论的技术。
如果您对此信息有任何疑问，我们将随时为您解答与本文相关问题的任何询问，每天 24 小时、每周 7 天、每年 365 天。
如果您是完全托管的 VPS 服务器， Cloud 专用，VMWare 私有 Cloud私有父服务器, 托管 Cloud 服务器或专用服务器所有者，并且您对执行概述的任何步骤感到不舒服，可以通过电话@800.580.4985 联系我们， 聊天 或支持票以帮助您完成此过程。
