Azure Database for MySQL 灵活服务器中的服务器参数

Artículo
12/23/2024

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

注意

本文包含对术语“从属”的引用，这是 Microsoft 不再使用的术语。在从软件中删除该术语后，我们会将其从本文中删除。

什么是服务器参数？

MySQL 引擎提供了可以用来配置和优化引擎行为的许多服务器参数（也称为变量）。某些参数可以在运行时动态设置。其他参数为静态，在设置这些参数后需要重启服务器。

在 Azure Database for MySQL 灵活服务器中，可以使用使用 Azure 门户在 Azure Database for MySQL 灵活服务器中配置服务器参数和使用 Azure CLI 在 Azure Database for MySQL 灵活服务器中配置服务器参数更改各种 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 的输出中作为守护程序进程列出。

对于 MySQL 版本 5.7 服务器，服务器参数 event_scheduler 会在备份开始后自动变为“OFF”，且服务器参数 event_scheduler 会在备份成功完成后重新变为“ON”。在适用于 Azure Database for MySQL 灵活服务器的 MySQL 版本 8.0 中，event_scheduler 在备份期间不受影响。为了确保运行更顺畅，建议使用主要版本升级将 MySQL 5.7 服务器升级到版本 8.0。

可以使用以下 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) |
| ``` |
| To configure the `event_scheduler` server parameter in Azure Database for MySQL - Flexible Server, perform the following steps: |

1. In the Azure portal, go to your Azure Database for MySQL - Flexible Server instance. Under **Settings**, select **Server parameters**.
1. On the **Server parameters** pane, search for `event_scheduler`. In the **VALUE** dropdown list, select **ON**, and then select **Save**.

    > [!NOTE]
    > Deployment of the dynamic configuration change to the server parameter doesn't require a restart.

1. To create an event, connect to the Azure Database for MySQL - Flexible Server instance and run the following SQL command:
    ```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());

    ```
1. To view the Event Scheduler details, run the following SQL statement:
    ```sql

    SHOW EVENTS;

    ```
    The following output appears:
    ```sql

    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) |
    | ``` |

1. After a few minutes, query the rows from the table to begin viewing the rows inserted every minute according to the `event_scheduler` parameter that you configured:

    ```azurecli
    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) |
    | ``` |
| 1. After an hour, run a `select` statement on the table to view the complete result of the values inserted into table every minute for an hour (as `event_scheduler` is configured in this case): |
    ```azurecli

    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) |
    | ``` |

#### Other scenarios

You can set up an event based on the requirements of your specific scenario. A few examples of scheduling SQL statements to run at various time intervals follow.

To run a SQL statement now and repeat one time per day with no end:

```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 在会话级别配置不可修改的服务器参数。

Compartir a través de

Azure Database for MySQL 灵活服务器中的服务器参数

什么是服务器参数？

可配置的服务器参数

lower_case_table_names

innodb_tmpdir

log_bin_trust_function_creators

innodb_buffer_pool_size

innodb_file_per_table

innodb_log_file_size

max_connections

innodb_strict_mode

time_zone

binlog_expire_logs_seconds

event_scheduler

配置 event_scheduler 服务器参数

限制

不可修改的服务器参数

Recursos adicionales

Compartir a través de

Azure Database for MySQL 灵活服务器中的服务器参数

什么是服务器参数？

可配置的服务器参数

lower_case_table_names

innodb_tmpdir

log_bin_trust_function_creators

innodb_buffer_pool_size

innodb_file_per_table

innodb_log_file_size

max_connections

innodb_strict_mode

time_zone

binlog_expire_logs_seconds

event_scheduler

配置 event_scheduler 服务器参数

限制

不可修改的服务器参数

相关内容

Recursos adicionales