你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure Database for MySQL 灵活服务器中的服务器参数
适用于：
Azure Database for MySQL - 灵活服务器
本文提供了在 Azure Database for MySQL 灵活服务器中配置服务器参数的注意事项和准则。
注意
本文包含对术语“从属”的引用，这是 Microsoft 不再使用的术语。 在从软件中删除该术语后，我们会将其从本文中删除。
什么是服务器变量？
MySQL 引擎提供了可以用来配置和优化引擎行为的许多不同的服务器变量/参数。 某些参数可在运行时动态设置，另外一些参数则为“静态”参数，需要重启服务器才能应用。
Azure Database for MySQL 灵活服务器公开了通过 Azure 门户和 Azure CLI 根据工作负载的需求更改各种 MySQL 服务器参数值的功能。
可配置的服务器参数
你可以使用服务器参数管理 Azure Database for MySQL 灵活服务器配置。 创建服务器时，将使用默认值和推荐值配置服务器参数。 Azure 门户上的“服务器参数”边栏选项卡显示了可修改的服务器参数和不可修改的服务器参数。 不可修改的服务器参数将灰显。
受支持服务器参数的列表还在不断增加。 在 Azure 门户中使用服务器参数选项卡可查看完整列表并配置服务器参数值。
请参阅以下各部分，详细了解几个经常更新的服务器参数的限制。 这些限制取决于服务器的计算层和大小 (vCore)。
注意
- 如果在门户中修改静态服务器参数，则需要重新启动服务器才能使更改生效。 如果使用自动化脚本（使用 ARM 模板、Terraform、Azure CLI 等工具），那么即使在创建体验过程中更改配置，你的脚本也应该会提供重启服务以使设置生效的预配项。
- 如果想要为环境修改不可修改的服务器参数，请打开 UserVoice 项，或者在反馈已经存在的情况下进行投票，这可以帮助我们确定优先级。
lower_case_table_names
如果使用的是 MySQL 5.7 版本，则 Azure Database for MySQL 灵活服务器中的默认值是 1。 请务必注意，虽然可以将支持的值更改为 2，但不能从 2 恢复回 1。 请联系我们的支持团队，获取更改默认值的帮助。 如果使用的是 MySQL 8.0 以上版本，当初始化服务器时只能配置 lower_case_table_names。 了解详细信息。 禁止在初始化服务器后更改 lower_case_table_names 设置。 如果使用的是 MySQL 8.0 版本，则 Azure Database for MySQL 灵活服务器中的默认值是 1。 在 Azure Database for MySQL 灵活服务器中，MySQL 版本 8.0 支持的值是 1 和 2。 请联系我们的支持团队，获取在创建服务器过程中更改默认值的帮助。
innodb_tmpdir
Azure Database for MySQL 灵活服务器中的 innodb_tmpdir 参数用于定义在重新生成的联机 ALTER TABLE 操作期间创建的临时排序文件的目录。 innodb_tmpdir 的默认值为 /mnt/temp。 此位置对应于临时存储 SSD，以 GiB 为单位，按每个服务器计算大小提供。 此位置非常适合不需要大量空间的操作。
如果需要更多空间，可以将 innodb_tmpdir 设置为 /app/work/tmpdir。 这会利用 Azure Database for MySQL 灵活服务器上的可用存储和容量。 这对于需要更多临时存储的大型操作非常有用。
请务必注意，与默认临时存储 (SSD) /mnt/temp 相比，利用 /app/work/tmpdir 会导致性能降低。 应根据操作的特定要求进行选择。
为 innodb_tmpdir 提供的信息适用于参数 innodb_temp_tablespaces_dir、tmpdir 和 Slave_load_tmpdir，其中默认值 /mnt/temp 是通用的，备用目录 /app/work/tmpdir 可用于配置增加的临时存储，并根据特定操作要求权衡性能。
log_bin_trust_function_creators
在 Azure Database for MySQL 灵活服务器中，二进制日志始终处于启用状态（即 log_bin 设置为“ON”）。 在灵活服务器中，log_bin_trust_function_creators 默认设置为“开启”。
二进制日志记录格式始终是“行”，所有与服务器的连接始终使用基于行的二进制日志记录。 使用基于行的二进制日志记录时，不存在安全问题并且二进制日志记录也不会中断，因此允许 log_bin_trust_function_creators 保持为“ON”是安全的。
如果 [log_bin_trust_function_creators] 设置为“关闭”，如果你尝试创建触发器，可能会收到如下错误消息：你没有“超级”权限且二进制日志记录已启用(你可能需要使用安全性更低的 log_bin_trust_function_creators 变量)”。
innodb_buffer_pool_size
查看 MySQL 文档详细了解此参数。 下表中的物理内存大小 (GB) 表示 Azure Database for MySQL 灵活服务器上的可用随机存取内存 (RAM)，以千兆字节 (GB) 为单位。
| 定价层 | vCore(s) | 物理内存大小 (GiB) | 默认值（字节） | 最小值（字节） | 最大值（字节） |
|---|---|---|---|---|---|
| 可突发 (B1s) | 1 | 1 | 134217728 | 33554432 | 268435456 |
| 可突发 (B1ms) | 1 | 2 | 536870912 | 134217728 | 1073741824 |
| 可突发 (B2s) | 2 | 4 | 2147483648 | 134217728 | 2147483648 |
| 可突发 (B2ms) | 2 | 8 | 4294967296 | 134217728 | 5368709120 |
| 可突发 | 4 | 16 | 12884901888 | 134217728 | 12884901888 |
| 可突发 | 8 | 32 | 25769803776 | 134217728 | 25769803776 |
| 可突发 | 12 | 48 | 51539607552 | 134217728 | 51539607552 |
| 可突发 | 16 | 64 | 2147483648 | 134217728 | 2147483648 |
| 可突发 | 20 | 80 | 64424509440 | 134217728 | 64424509440 |
| 常规用途 | 2 | 8 | 4294967296 | 134217728 | 5368709120 |
| 常规用途 | 4 | 16 | 12884901888 | 134217728 | 12884901888 |
| 常规用途 | 8 | 32 | 25769803776 | 134217728 | 25769803776 |
| 常规用途 | 16 | 64 | 51539607552 | 134217728 | 51539607552 |
| 常规用途 | 32 | 128 | 103079215104 | 134217728 | 103079215104 |
| 常规用途 | 48 | 192 | 154618822656 | 134217728 | 154618822656 |
| 常规用途 | 64 | 256 | 206158430208 | 134217728 | 206158430208 |
| 业务关键 | 2 | 16 | 12884901888 | 134217728 | 12884901888 |
| 业务关键 | 4 | 32 | 25769803776 | 134217728 | 25769803776 |
| 业务关键 | 8 | 64 | 51539607552 | 134217728 | 51539607552 |
| 业务关键 | 16 | 128 | 103079215104 | 134217728 | 103079215104 |
| 业务关键 | 20 | 160 | 128849018880 | 134217728 | 128849018880 |
| 业务关键 | 32 | 256 | 206158430208 | 134217728 | 206158430208 |
| 业务关键 | 48 | 384 | 309237645312 | 134217728 | 309237645312 |
| 业务关键 | 64 | 504 | 405874409472 | 134217728 | 405874409472 |
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 表空间中创建表。
对于单个数据文件，Azure Database for MySQL 灵活服务器支持的最大大小为 8 TB。 如果你的数据库大小超过 8 TB，应在 innodb_file_per_table 表空间中创建表。 如果单个表的大小超过 8 TB，应使用分区表。
innodb_log_file_size
innodb_log_file_size 表示日志组中每个日志文件的大小（以字节为单位）。 日志文件的合并大小 (innodb_log_file_size * innodb_log_files_in_group) 不能超过最大值（最大值是一个略小于 512 GB 的值）。 日志文件大小越大，性能越好，但有一个缺点，即故障后的恢复时间会很长。 你需要平衡极少发生的故障恢复事件中的恢复时间与高峰操作期间最大吞吐量之间的关系。 这还可能导致重启时间延长。 你可以将 innodb_log_size 配置为以下任意值：256 MB、512 MB、1 GB 或 2 GB（适用于 Azure Database for MySQL 灵活服务器）。 参数是静态的，需要重启。
注意
如果将参数 innodb_log_file_size 从默认值更改为其他值，请检查“显示全局状态，如‘innodb_buffer_pool_pages_dirty’”的值是否在 30 秒的时间内保持为 0，以避免重新启动延迟。
max_connections
max_connection 的值取决于服务器的内存大小。 下表中的物理内存大小 (GB) 表示 Azure Database for MySQL 灵活服务器上的可用随机存取内存 (RAM)，以千兆字节 (GB) 为单位。
| 定价层 | vCore(s) | 物理内存大小 (GiB) | 默认值 | 最小值 | 最大值 |
|---|---|---|---|---|---|
| 可突发 (B1s) | 1 | 1 | 85 | 10 | 171 |
| 可突发 (B1ms) | 1 | 2 | 171 | 10 | 341 |
| 可突发 (B2s) | 2 | 4 | 341 | 10 | 683 |
| 可突发 (B2ms) | 2 | 4 | 683 | 10 | 1365 |
| 可突发 | 4 | 16 | 1365 | 10 | 2731 |
| 可突发 | 8 | 32 | 2731 | 10 | 5461 |
| 可突发 | 12 | 48 | 4097 | 10 | 8193 |
| 可突发 | 16 | 64 | 5461 | 10 | 10923 |
| 可突发 | 20 | 80 | 6827 | 10 | 13653 |
| 常规用途 | 2 | 8 | 683 | 10 | 1365 |
| 常规用途 | 4 | 16 | 1365 | 10 | 2731 |
| 常规用途 | 8 | 32 | 2731 | 10 | 5461 |
| 常规用途 | 16 | 64 | 5461 | 10 | 10923 |
| 常规用途 | 32 | 128 | 10923 | 10 | 21845 |
| 常规用途 | 48 | 192 | 16384 | 10 | 32768 |
| 常规用途 | 64 | 256 | 21845 | 10 | 43691 |
| 业务关键 | 2 | 16 | 1365 | 10 | 2731 |
| 业务关键 | 4 | 32 | 2731 | 10 | 5461 |
| 业务关键 | 8 | 64 | 5461 | 10 | 10923 |
| 业务关键 | 16 | 128 | 10923 | 10 | 21845 |
| 业务关键 | 20 | 160 | 13653 | 10 | 27306 |
| 业务关键 | 32 | 256 | 21845 | 10 | 43691 |
| 业务关键 | 48 | 384 | 32768 | 10 | 65536 |
| 业务关键 | 64 | 504 | 43008 | 10 | 86016 |
当连接数超出限制时，可能会收到以下错误：
错误 1040 (08004)：连接过多
重要
为了获得最佳体验，建议使用 ProxySQL 等连接池程序来高效地管理连接。
创建与 MySQL 的新客户端连接需要时间，一旦建立，这些连接就会占用数据库资源，即使在空闲时也是如此。 大多数应用程序请求许多生存期短的连接，这加剧了这种情况。 其结果是可用于实际工作负荷的资源减少，从而导致性能下降。 连接池程序不仅会减少空闲连接，还会重用现有连接，因而有助于避免这种情况。 若要了解如何设置 ProxySQL，请访问我们的博客文章。
注意
ProxySQL 是一个开源社区工具。 Microsoft 尽最大努力为它提供支持。 若要获得包含权威指导的生产支持，可以评估并联系 ProxySQL 产品支持。
innodb_strict_mode
如果收到类似于“行大小太大(> 8126)”的错误，则可能需要禁用 innodb_strict_mode 参数。 不能在服务器级别全局修改服务器参数 innodb_strict_mode，因为如果行数据大小大于 8k，该数据将会被截断，且不显示错误，这可能会导致数据丢失。 建议修改架构以适应页面大小限制。
可以使用 init_connect 在会话级别设置此参数。 若要在会话级别设置 innodb_strict_mode，请参阅设置未列出的参数。
注意
如果有只读副本服务器，在源服务器上的会话级别将 innodb_strict_mode 设置为 OFF 会中断复制。 如果有只读副本，建议将该参数始终设置为 ON。
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 门户中，导航到 Azure Database for MySQL 灵活服务器实例，然后在“设置”下选择“服务器参数”。
在“服务器参数”边栏选项卡上，搜索
event_scheduler，在“值”下拉列表中选择“ON”，然后选择“保存”。注意
动态服务器参数配置更改将在不重启的情况下进行部署。
然后，若要创建事件，请连接到 Azure Database for 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>;
限制
对于配置了高可用性的服务器，发生故障转移时，event_scheduler 服务器参数可能会设置为“OFF”。 如果发生这种情况，故障转移完成后，请配置该参数以将值设置为“ON”。
不可修改的服务器参数
Azure 门户上的服务器参数边栏选项卡将同时显示可修改和不可修改的服务器参数。 不可修改的服务器参数将灰显。如果要在会话级别配置不可修改的服务器参数，请参阅 Azure 门户或 Azure CLI 文章，了解如何使用 init_connect 在连接级别设置该类参数。
后续步骤
- 如何配置 Azure 门户中的服务器参数
- 如何配置 Azure CLI 中的服务器参数