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 门户定期查看服务器参数的完整列表并配置值。
如果在门户中修改静态服务器参数，则需要重新启动服务器才能使更改生效。 如果使用自动化脚本（通过 Azure 资源管理器模板、Terraform 或 Azure CLI 等工具），那么即使在创建体验过程中更改配置，脚本也应该会提供重启服务以使设置生效的预配项。
以下几个部分介绍常用更新的服务器参数的限制。 服务器的计算层和大小 (vCore) 确定限制。
lower_case_table_names
对于 MySQL 5.7 版本中，在 Azure Database for MySQL - 灵活服务器中，lower_case_table_names 的默认值为 1。 尽管可以将支持的值更改为 2，但不允许从 2 重新还原为 1。 有关更改默认值的帮助，请创建支持票证。
对于 MySQL 版本 8.0+，只能在初始化服务器时配置 lower_case_table_names。 了解详细信息。 禁止在初始化服务器后更改 lower_case_table_names 设置。
在 Azure Database for MySQL - 灵活服务器中，MySQL 版本 8.0 支持的值是 1 和 2。 默认值为 1。 有关在创建服务器过程中更改默认值的帮助，请创建支持票证。
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 参数在灵活服务器中设置为 ON。
二进制日志记录格式始终是 ROW，并且与服务器的连接始终使用基于行的二进制日志记录。 使用基于行的二进制日志记录时，不存在安全问题并且二进制日志记录也不会中断，因此允许 log_bin_trust_function_creators 保持为 ON 是安全的。
如果将 log_bin_trust_function_creators 设置为 OFF，如果你尝试创建触发器，可能会收到如下错误消息：“你没有‘超级’权限且二进制日志记录已启用(你可能需要使用安全性更低的 log_bin_trust_function_creators 变量)”。
innodb_buffer_pool_size
要了解 innodb_buffer_pool_size 参数，请查看 MySQL 文档。
下表中的物理内存大小表示 Azure Database for MySQL 灵活服务器上的可用随机存取内存 (RAM)，以千兆字节 (GB) 为单位。
| 定价层 | vCore 数 | 物理内存大小 (GB) | 默认值（字节） | 最小值（字节） | 最大值（字节） |
|---|---|---|---|---|---|
| 可突发 (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 的值）。
日志文件大小越大，性能越好，但缺点是故障后的恢复时间会很长。 需要平衡极少发生的故障事件中的恢复时间与高峰操作期间最大吞吐量之间的关系。 更大的日志文件大小也会导致重启时间更长。
对于 Azure Database for MySQL - 灵活服务器，可以将 innodb_log_size 配置为 256 兆字节 (MB)、512 MB、1 GB 或 2 GB。 参数是静态的，需要重启。
注意
如果更改了 innodb_log_file_size 参数的默认值，请检查值 show global status like 'innodb_buffer_pool_pages_dirty' 的值是否保持 0 30 秒，以避免重启延迟。
max_connections
服务器的内存大小确定 max_connections 的值。 下表中的物理内存大小表示 Azure Database for MySQL 灵活服务器上的可用 RAM，以千兆字节为单位。
| 定价层 | vCore 数 | 物理内存大小 (GB) | 默认值 | 最小值 | 最大值 |
|---|---|---|---|---|---|
| 可突发 (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)：连接过多”。
创建客户端与 MySQL 的新连接需要一段时间。 建立这些连接后，即使它们处于空闲状态，它们也会占用数据库资源。 大多数应用程序会请求许多生存期短的连接，这加剧了这种情况。 其结果是可用于实际工作负荷的资源减少，从而导致性能下降。
连接池程序不仅会减少空闲连接，还会重用现有连接，因而有助于避免出现这个问题。 为了获得最佳体验，建议使用 ProxySQL 等连接池程序来高效地管理连接。 若要了解如何设置 ProxySQL，请参阅这篇博客文章。
注意
ProxySQL 是一个开源社区工具。 Microsoft 尽最大努力提供支持。 若要获得权威指导的生产支持，请联系 ProxySQL 产品支持。
innodb_strict_mode
如果收到类似于“行大小太大(> 8126)”的错误，则可能会想要关闭 innodb_strict_mode 服务器参数。 无法在服务器级别全局修改此参数，因为如果行数据大小大于 8K，则数据将被截断而不会出错。 这种截断可能会导致潜在的数据丢失。 建议修改架构以适应页面大小限制。
可以使用 init_connect 在会话级别设置此参数。 有关详细信息，请参阅设置不可修改的服务器参数。
注意
如果有只读副本服务器，在源服务器上的会话级别将 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 参数。 如果将 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_scheduler 服务器参数管理创建、计划和运行事件。 也就是说，该参数管理由特殊 MySQL Event Scheduler 线程根据计划运行的任务。 当将 event_scheduler 参数设置为 ON 时，Event Scheduler 线程将在 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 在会话级别配置不可修改的服务器参数。