Azure Database for MySQL 中的服务器参数

项目
04/26/2023

适用于： Azure Database for MySQL - 单一服务器

重要

Azure Database for MySQL 单一服务器即将停用。强烈建议升级到 Azure Database for MySQL 灵活服务器。有关如何迁移到 Azure Database for MySQL 灵活服务器的详细信息，请参阅 Azure Database for MySQL 单一服务器发生了什么情况？

本文提供了在 Azure Database for MySQL 中配置服务器参数的注意事项和准则。

什么是服务器参数？

MySQL 引擎提供了许多不同的服务器变量和参数，你可以使用这些变量和参数来配置和优化引擎行为。某些参数可在运行时动态设置，另外一些参数则为静态，需要重启服务器才能应用。

Azure Database for MySQL 公开了使用 Azure 门户、Azure CLI 和 PowerShell 来更改各种 MySQL 服务器参数值以满足工作负载需求的功能。

可配置的服务器参数

受支持服务器参数的列表还在不断增加。在 Azure 门户中，使用服务器参数选项卡可查看完整列表并配置服务器参数值。

请参阅以下各部分，详细了解多个经常更新的服务器参数的限制。这些限制取决于服务器的定价层和 vCore 数。

线程池

MySQL 通常会为每个客户端连接分配一个线程。随着并发用户数量的增加，性能会相应下降。由于上下文切换增加、线程争用以及 CPU 缓存位置不正确，许多活动线程会严重影响性能。

线程池是一种服务器端功能，与连接池不同，它通过引入动态工作线程池来最大限度地提高性能。使用此功能可以限制服务器上运行的活动线程数，并最大程度地减少线程改动。这有助于确保突发连接不会导致服务器耗尽资源或内存。对于短查询和 CPU 密集型工作负载（例如 OLTP 工作负载），线程池最有效。

有关详细信息，请参阅在 Azure Database for MySQL 中引入线程池。

注意

MySQL 5.6 不支持线程池。

配置线程池

若要启用线程池，请将 thread_handling 服务器参数更新为 pool-of-threads。默认情况下，此参数设置为 one-thread-per-connection，这意味着 MySQL 会为每个新连接创建一个新线程。这是一个静态参数，需要重启服务器才能应用。

还可通过设置以下服务器参数，配置池中的最大和最小线程数：

thread_pool_max_threads：此值限制池中的线程数。
thread_pool_min_threads：此值设置即使在连接关闭后也会保留的线程数。

若要改善线程池上短查询的性能问题，可以启用“批处理执行”。线程不会在运行查询后立即返回到线程池，而是在短时间内保持活动状态，以通过此连接等待下一个查询。然后，线程快速运行查询，完成此操作后，线程将等待下一个查询。此过程将一直持续到花费的总时间超过阈值。

通过使用以下服务器参数确定批处理执行的行为：

thread_pool_batch_wait_timeout：此值指定线程等待另一个查询进行处理的时间。
thread_pool_batch_max_time：此值确定线程重复查询执行周期并等待下一个查询的最长时间。

重要

在测试线程池之前，不要在生产环境中打开线程池。

log_bin_trust_function_creators

在 Azure Database for MySQL 中，始终启用二进制日志（即，将 log_bin 参数设置为 ON）。如果你想使用触发器，则会收到如下错误：你没有 SUPER 权限且二进制日志记录已启用（你可能需要使用安全性更低的 log_bin_trust_function_creators 变量）。

二进制日志记录格式始终是“行”，所有与服务器的连接始终使用基于行的二进制日志记录。基于行的二进制日志记录有助于维护安全性，并且二进制日志记录不会中断，因此可以安全地将 log_bin_trust_function_creators 设置为 TRUE。

innodb_buffer_pool_size

查看 MySQL 文档详细了解此参数。

使用常规用途存储 v1（最多支持 4 TB）的服务器

定价层	vCore(s)	默认值（字节）	最小值（字节）	最大值（字节）
基本	1	872415232	134217728	872415232
基本	2	2684354560	134217728	2684354560
常规用途	2	3758096384	134217728	3758096384
常规用途	4	8053063680	134217728	8053063680
常规用途	8	16106127360	134217728	16106127360
常规用途	16	32749125632	134217728	32749125632
常规用途	32	66035122176	134217728	66035122176
常规用途	64	132070244352	134217728	132070244352
内存优化	2	7516192768	134217728	7516192768
内存优化	4	16106127360	134217728	16106127360
内存优化	8	32212254720	134217728	32212254720
内存优化	16	65498251264	134217728	65498251264
内存优化	32	132070244352	134217728	132070244352

使用常规用途存储 v2（最多支持 16 TB）的服务器

定价层	vCore(s)	默认值（字节）	最小值（字节）	最大值（字节）
基本	1	872415232	134217728	872415232
基本	2	2684354560	134217728	2684354560
常规用途	2	7516192768	134217728	7516192768
常规用途	4	16106127360	134217728	16106127360
常规用途	8	32212254720	134217728	32212254720
常规用途	16	65498251264	134217728	65498251264
常规用途	32	132070244352	134217728	132070244352
常规用途	64	264140488704	134217728	264140488704
内存优化	2	15032385536	134217728	15032385536
内存优化	4	32212254720	134217728	32212254720
内存优化	8	64424509440	134217728	64424509440
内存优化	16	130996502528	134217728	130996502528
内存优化	32	264140488704	134217728	264140488704

innodb_file_per_table

MySQL 根据你在表创建期间提供的配置，将 InnoDB 表存储在不同的表空间中。系统表空间是 InnoDB 数据字典的存储区域。 file-per-table 表空间包含单个 InnoDB 表的数据和索引，并存储在文件系统内它自己的数据文件中。

可以使用 innodb_file_per_table 服务器参数来控制此行为。将 innodb_file_per_table 设置为 OFF 会导致 InnoDB 在系统表空间中创建表。否则，InnoDB 将在 file-per-table 表空间中创建表。

注意

innodb_file_per_table 只能在常规用途存储 v2 和常规用途存储 v1 的“常规用途”和“内存优化”定价层中进行更新。

在常规用途存储 v2 上的单个数据文件中，Azure Database for MySQL 最多支持 4 TB。如果数据库大小超过 4 TB，应在 innodb_file_per_table 表空间中创建表。如果单个表的大小超过 4 TB，应使用分区表。

join_buffer_size

查看 MySQL 文档详细了解此参数。

定价层	vCore(s)	默认值（字节）	最小值（字节）	最大值（字节）
基本	1	在基本层中不可配置	不适用	不适用
基本	2	在基本层中不可配置	不适用	不适用
常规用途	2	262144	128	268435455
常规用途	4	262144	128	536870912
常规用途	8	262144	128	1073741824
常规用途	16	262144	128	2147483648
常规用途	32	262144	128	4294967295
常规用途	64	262144	128	4294967295
内存优化	2	262144	128	536870912
内存优化	4	262144	128	1073741824
内存优化	8	262144	128	2147483648
内存优化	16	262144	128	4294967295
内存优化	32	262144	128	4294967295

max_connections

定价层	vCore(s)	默认值	最小值	最大值
基本	1	50	10	50
基本	2	100	10	100
常规用途	2	300	10	600
常规用途	4	625	10	1250
常规用途	8	1250	10	2500
常规用途	16	2500	10	5000
常规用途	32	5000	10	10000
常规用途	64	10000	10	20000
内存优化	2	625	10	1250
内存优化	4	1250	10	2500
内存优化	8	2500	10	5000
内存优化	16	5000	10	10000
内存优化	32	10000	10	20000

当连接数超过限制时，可能会收到错误。

提示

若要有效地管理连接，最好使用连接池程序，如 ProxySQL。若要了解如何设置 ProxySQL，请参阅博客文章在 Azure Database for MySQL 中使用 ProxySQL 对只读副本进行负载均衡。请注意 ProxySQL 是一个开源社区工具。 Microsoft 尽最大努力为它提供支持。

max_heap_table_size

查看 MySQL 文档详细了解此参数。

定价层	vCore(s)	默认值（字节）	最小值（字节）	最大值（字节）
基本	1	在基本层中不可配置	不适用	不适用
基本	2	在基本层中不可配置	不适用	不适用
常规用途	2	16777216	16384	268435455
常规用途	4	16777216	16384	536870912
常规用途	8	16777216	16384	1073741824
常规用途	16	16777216	16384	2147483648
常规用途	32	16777216	16384	4294967295
常规用途	64	16777216	16384	4294967295
内存优化	2	16777216	16384	536870912
内存优化	4	16777216	16384	1073741824
内存优化	8	16777216	16384	2147483648
内存优化	16	16777216	16384	4294967295
内存优化	32	16777216	16384	4294967295

query_cache_size

默认会禁用查询缓存。若要启用查询缓存，请配置 query_cache_type 参数。

查看 MySQL 文档详细了解此参数。

注意

自 MySQL 5.7.20 起，查询缓存已被弃用；在 MySQL 8.0 中，查询缓存已被删除。

定价层	vCore(s)	默认值（字节）	最小值（字节）	最大值
基本	1	在基本层中不可配置	不适用	不适用
基本	2	在基本层中不可配置	不适用	不适用
常规用途	2	0	0	16777216
常规用途	4	0	0	33554432
常规用途	8	0	0	67108864
常规用途	16	0	0	134217728
常规用途	32	0	0	134217728
常规用途	64	0	0	134217728
内存优化	2	0	0	33554432
内存优化	4	0	0	67108864
内存优化	8	0	0	134217728
内存优化	16	0	0	134217728
内存优化	32	0	0	134217728

lower_case_table_names

lower_case_table_name 参数默认设置为 1，你可以在 MySQL 5.6 和 MySQL 5.7 中更新此参数。

查看 MySQL 文档详细了解此参数。

注意

在 MySQL 8.0 中，lower_case_table_name 默认设置为 1，你无法更改它。

innodb_strict_mode

如果收到类似于 Row size too large (> 8126) 的错误，请考虑禁用 innodb_strict_mode 参数。无法在服务器级别全局修改 innodb_strict_mode。如果行数据大小大于 8K，则数据将被截断，且不会发出错误通知，从而导致潜在的数据丢失。最好修改架构以适应页面大小限制。

可以使用 init_connect 在会话级别设置此参数。若在会话级别设置 innodb_strict_mode，请参阅未列出的设置参数。

注意

如果有只读副本服务器，在源服务器上的会话级别将 innodb_strict_mode 设置为 OFF 会中断复制。如果有只读副本，建议将该参数始终设置为 ON。

sort_buffer_size

查看 MySQL 文档详细了解此参数。

定价层	vCore(s)	默认值（字节）	最小值（字节）	最大值（字节）
基本	1	在基本层中不可配置	不适用	不适用
基本	2	在基本层中不可配置	不适用	不适用
常规用途	2	524288	32768	4194304
常规用途	4	524288	32768	8388608
常规用途	8	524288	32768	16777216
常规用途	16	524288	32768	33554432
常规用途	32	524288	32768	33554432
常规用途	64	524288	32768	33554432
内存优化	2	524288	32768	8388608
内存优化	4	524288	32768	16777216
内存优化	8	524288	32768	33554432
内存优化	16	524288	32768	33554432
内存优化	32	524288	32768	33554432

tmp_table_size

查看 MySQL 文档详细了解此参数。

定价层	vCore(s)	默认值（字节）	最小值（字节）	最大值（字节）
基本	1	在基本层中不可配置	不适用	不适用
基本	2	在基本层中不可配置	不适用	不适用
常规用途	2	16777216	1024	67108864
常规用途	4	16777216	1024	134217728
常规用途	8	16777216	1024	268435456
常规用途	16	16777216	1024	536870912
常规用途	32	16777216	1024	1073741824
常规用途	64	16777216	1024	1073741824
内存优化	2	16777216	1024	134217728
内存优化	4	16777216	1024	268435456
内存优化	8	16777216	1024	536870912
内存优化	16	16777216	1024	1073741824
内存优化	32	16777216	1024	1073741824

InnoDB 缓冲池预热

重启 Azure Database for MySQL 后，在查询表时，将加载驻留在磁盘中的数据页。这会导致第一次运行查询时延迟增加和性能降低。对于对延迟敏感的工作负载，你可能会发现这种性能降低是不可接受的。

可以使用 InnoDB 缓冲池预热来缩短预热周期。此过程重新加载在重启之前位于缓冲池中的磁盘页，而不是等待 DML 或 SELECT 操作访问相应的行。有关详细信息，请参阅 InnoDB 缓冲池服务器参数。

但是，性能的提高是以服务器启动时间的延长为代价的。启用此参数后，预计服务器启动和重启时间会增加，具体取决于服务器上预配的 IOPS。建议测试和监视重启时间，以确保启动/重启性能是可接受的，因为在此期间服务器不可用。当预配的 IOPS 数小于 1000 IOPS（或换句话说，当预配的存储小于 335 GB）时，请勿使用此参数。

要在服务器关闭时保存缓冲池的状态，请将服务器参数 innodb_buffer_pool_dump_at_shutdown 设置为 ON。同样，将服务器参数 innodb_buffer_pool_load_at_startup 设置为 ON 以在服务器启动时还原缓冲池状态。可以通过降低和微调服务器参数 innodb_buffer_pool_dump_pct 的值来控制对启动或重启时间的影响。默认情况下，此参数设置为 25。

注意

仅存储容量最大达 16 TB 的常规用途存储服务器才支持 InnoDB 缓冲池预热参数。有关详细信息，请参阅 Azure Database for MySQL 存储选项。

time_zone

在初始部署时，运行 Azure Database for MySQL 的服务器包含用于时区信息的系统表，但这些表没有填充。可以通过从 MySQL 命令行或 MySQL Workbench 等工具调用 mysql.az_load_timezone 存储过程来填充表。有关如何调用存储过程以及设置全局或会话级时区的信息，请参阅使用时区参数（Azure 门户）或使用时区参数 (Azure CLI)。

binlog_expire_logs_seconds

在 Azure Database for MySQL 中，此参数指定在清除二进制日志文件之前，服务等待的秒数。

二进制日志包含描述数据库更改（例如表创建操作或对表数据所做的更改）的事件。它还包含可能进行更改的语句的事件。二进制日志主要用于两个目的：复制和数据恢复操作。

通常，当句柄从服务、备份或副本集中释放后，二进制日志就会立即被清除。如果有多个副本，二进制日志将等待速度最慢的副本读取更改，然后再清除。如果希望二进制日志保留更长时间，则可以配置参数 binlog_expire_logs_seconds。如果将 binlog_expire_logs_seconds 设置为 0（这是默认值），则在释放二进制日志的句柄后立即清除。如果将 binlog_expire_logs_seconds 设置为大于 0，则二进制日志仅在该时间段后清除。

对于 Azure Database for MySQL，二进制文件的备份和只读副本清除等托管功能都是在内部处理的。复制从 Azure Database for MySQL 服务中输出的数据时，必须在主副本中设置此参数，以避免在副本从主副本读取更改之前清除二进制日志。如果将 binlog_expire_logs_seconds 设置为更高的值，则不会很快清除二进制日志。这可能会导致存储计费增加。

event_scheduler

在 Azure Database for MySQL 中，event_schedule 服务器参数将管理事件的创建、计划和运行，即按计划运行的任务，这些任务由特殊的事件计划程序线程运行。当 event_scheduler 参数设置为 ON 时，事件计划程序线程将在 SHOW PROCESSLIST 的输出中作为守护程序进程列出。可以使用以下 SQL 语法创建和计划事件：

CREATE EVENT <event name>
ON SCHEDULE EVERY _ MINUTE / HOUR / DAY
STARTS TIMESTAMP / CURRENT_TIMESTAMP
ENDS TIMESTAMP / CURRENT_TIMESTAMP + INTERVAL 1 MINUTE / HOUR / DAY
COMMENT ‘<comment>’
DO
<your statement>;

注意

有关创建事件的详细信息，请参阅以下 MySQL Event Scheduler 文档：

配置 event_scheduler 服务器参数

以下方案演示了在 Azure Database for MySQL 中使用 event_scheduler 参数的一种方法。若要演示此方案，请考虑以下示例，即一个简单的表：

mysql> describe tab1;
+-----------+-------------+------+-----+---------+----------------+
| Field     | Type        | Null | Key | Default | Extra          |
+-----------+-------------+------+-----+---------+----------------+
| id        | int(11)     | NO   | PRI | NULL    | auto_increment |
| CreatedAt | timestamp   | YES  |     | NULL    |                |
| CreatedBy | varchar(16) | YES  |     | NULL    |                |
+-----------+-------------+------+-----+---------+----------------+
3 rows in set (0.23 sec)

若要在 Azure Database for MySQL 中配置 event_scheduler 服务器参数，请执行以下步骤：

在 Azure 门户中，导航到你的服务器，然后在“设置”下选择“服务器参数”。
在“服务器参数”边栏选项卡上，搜索 event_scheduler，在“值”下拉列表中选择“ON”，然后选择“保存”。

注意

动态服务器参数配置更改将在不重启的情况下进行部署。

然后，若要创建事件，请连接到 MySQL 服务器，然后运行以下 SQL 命令：

CREATE EVENT test_event_01
ON SCHEDULE EVERY 1 MINUTE
STARTS CURRENT_TIMESTAMP
ENDS CURRENT_TIMESTAMP + INTERVAL 1 HOUR
COMMENT ‘Inserting record into the table tab1 with current timestamp’
DO
INSERT INTO tab1(id,createdAt,createdBy)
VALUES('',NOW(),CURRENT_USER());

若要查看 Event Scheduler 详细信息，请运行以下 SQL 语句：

SHOW EVENTS;

随即显示以下输出：

mysql> show events;
+-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+
| Db  | Name          | Definer     | Time zone | Type      | Execute at | Interval value | Interval field | Starts              | Ends                | Status  | Originator | character_set_client | collation_connection | Database Collation |
+-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+
| db1 | test_event_01 | azureuser@% | SYSTEM    | RECURRING | NULL       | 1              | MINUTE         | 2023-04-05 14:47:04 | 2023-04-05 15:47:04 | ENABLED | 3221153808 | latin1               | latin1_swedish_ci    | latin1_swedish_ci  |
+-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+
1 row in set (0.23 sec)

几分钟后，查询表中的行，开始根据配置的 event_scheduler 参数查看每分钟插入的行：

mysql> select * from tab1;
+----+---------------------+-------------+
| id | CreatedAt           | CreatedBy   |
+----+---------------------+-------------+
|  1 | 2023-04-05 14:47:04 | azureuser@% |
|  2 | 2023-04-05 14:48:04 | azureuser@% |
|  3 | 2023-04-05 14:49:04 | azureuser@% |
|  4 | 2023-04-05 14:50:04 | azureuser@% |
+----+---------------------+-------------+
4 rows in set (0.23 sec)

一小时后，对表运行 Select 语句，查看每分钟插入表中的值的完整结果，持续一小时，因为在本例中 event_scheduler 已配置。

mysql> select * from tab1;
+----+---------------------+-------------+
| id | CreatedAt           | CreatedBy   |
+----+---------------------+-------------+
|  1 | 2023-04-05 14:47:04 | azureuser@% |
|  2 | 2023-04-05 14:48:04 | azureuser@% |
|  3 | 2023-04-05 14:49:04 | azureuser@% |
|  4 | 2023-04-05 14:50:04 | azureuser@% |
|  5 | 2023-04-05 14:51:04 | azureuser@% |
|  6 | 2023-04-05 14:52:04 | azureuser@% |
..< 50 lines trimmed to compact output >..
| 56 | 2023-04-05 15:42:04 | azureuser@% |
| 57 | 2023-04-05 15:43:04 | azureuser@% |
| 58 | 2023-04-05 15:44:04 | azureuser@% |
| 59 | 2023-04-05 15:45:04 | azureuser@% |
| 60 | 2023-04-05 15:46:04 | azureuser@% |
| 61 | 2023-04-05 15:47:04 | azureuser@% |
+----+---------------------+-------------+
61 rows in set (0.23 sec)

其他方案

可以根据特定方案的要求设置事件。下面是一些安排 SQL 语句在不同时间间隔运行的类似示例。

立即运行 SQL 语句，每天重复一次，没有结束时间

CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 DAY
STARTS (TIMESTAMP(CURRENT_DATE) + INTERVAL 1 DAY + INTERVAL 1 HOUR)
COMMENT 'Comment'
DO
<your statement>;

每小时运行一次 SQL 语句，没有结束时间

CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 HOUR
COMMENT 'Comment'
DO
<your statement>;

每天运行一次 SQL 语句，没有结束时间

CREATE EVENT <event name>
ON SCHEDULE 
EVERY 1 DAY
STARTS str_to_date( date_format(now(), '%Y%m%d 0200'), '%Y%m%d %H%i' ) + INTERVAL 1 DAY
COMMENT 'Comment'
DO
<your statement>;

不可配置的服务器参数

以下服务器参数在服务中不可配置：

参数	固定值
基本层中的 `innodb_file_per_table`	OFF
`innodb_flush_log_at_trx_commit`	1
`sync_binlog`	1
`innodb_log_file_size`	256 MB
`innodb_log_files_in_group`	2

此处未列出的其他变量将设置为默认的 MySQL 值。有关版本 8.0、5.7 和 5.6，请参阅 MySQL 文档。

通过

Azure Database for MySQL 中的服务器参数

什么是服务器参数？

可配置的服务器参数

线程池

配置线程池

log_bin_trust_function_creators

innodb_buffer_pool_size

使用常规用途存储 v1（最多支持 4 TB）的服务器

使用常规用途存储 v2（最多支持 16 TB）的服务器

innodb_file_per_table

join_buffer_size

max_connections

max_heap_table_size

query_cache_size

lower_case_table_names

innodb_strict_mode

sort_buffer_size

tmp_table_size

InnoDB 缓冲池预热

time_zone

binlog_expire_logs_seconds

event_scheduler

配置 event_scheduler 服务器参数

其他方案

不可配置的服务器参数

后续步骤

其他资源