通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

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

  • 项目

本文提供了在 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) 默认值（字节） 最小值（字节） 最大值（字节）
可突发
Standard_B1s 1 1 134217728 33554432 268435456
Standard_B1ms 1 2 536870912 134217728 1073741824
Standard_B2s 2 4 2147483648 134217728 2147483648
Standard_B2ms 2 8 4294967296 134217728 5368709120
Standard_B4ms 4 16 12884901888 134217728 12884901888
Standard_B8ms 8 32 25769803776 134217728 25769803776
Standard_B12ms 12 48 51539607552 134217728 32212254720
Standard_B16ms 16 64 2147483648 134217728 51539607552
Standard_B20ms 20 80 64424509440 134217728 64424509440
常规用途
Standard_D2ads_v5 2 8 4294967296 134217728 5368709120
Standard_D2ds_v4 2 8 4294967296 134217728 5368709120
Standard_D4ads_v5 4 16 12884901888 134217728 12884901888
Standard_D4ds_v4 4 16 12884901888 134217728 12884901888
Standard_D8ads_v5 8 32 25769803776 134217728 25769803776
Standard_D8ds_v4 8 32 25769803776 134217728 25769803776
Standard_D16ads_v5 16 64 51539607552 134217728 51539607552
Standard_D16ds_v4 16 64 51539607552 134217728 51539607552
Standard_D32ads_v5 32 128 103079215104 134217728 103079215104
Standard_D32ds_v4 32 128 103079215104 134217728 103079215104
Standard_D48ads_v5 48 192 154618822656 134217728 154618822656
Standard_D48ds_v4 48 192 154618822656 134217728 154618822656
Standard_D64ads_v5 64 256 206158430208 134217728 206158430208
Standard_D64ds_v4 64 256 206158430208 134217728 206158430208
业务关键
Standard_E2ds_v4 2 16 12884901888 134217728 12884901888
Standard_E2ads_v5、Standard_E2ds_v5 2 16 12884901888 134217728 12884901888
Standard_E4ds_v4 4 32 25769803776 134217728 25769803776
Standard_E4ads_v5、Standard_E4ds_v5 4 32 25769803776 134217728 25769803776
Standard_E8ds_v4 8 64 51539607552 134217728 51539607552
Standard_E8ads_v5、Standard_E8ds_v5 8 64 51539607552 134217728 51539607552
Standard_E16ds_v4 16 128 103079215104 134217728 103079215104
Standard_E16ads_v5、Standard_E16ds_v5 16 128 103079215104 134217728 103079215104
Standard_E20ds_v4 20 160 128849018880 134217728 128849018880
Standard_E20ads_v5、Standard_E20ds_v5 20 160 128849018880 134217728 128849018880
Standard_E32ds_v4 32 256 206158430208 134217728 206158430208
Standard_E32ads_v5、Standard_E32ds_v5 32 256 206158430208 134217728 206158430208
Standard_E48ds_v4 48 384 309237645312 134217728 309237645312
Standard_E48ads_v5、Standard_E48ds_v5 48 384 309237645312 134217728 309237645312
Standard_E64ds_v4 64 504 405874409472 134217728 405874409472
Standard_E64ads_v5、Standard_E64ds_v5 64 512 412316860416 134217728 412316860416
Standard_E80ids_v4 80 504 405874409472 134217728 405874409472
Standard_E96ds_v5 96 672 541165879296 134217728 541165879296

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) 默认值 最小值 最大值
可突发
Standard_B1s 1 1 85 10 171
Standard_B1ms 1 2 171 10 341
Standard_B2s 2 4 341 10 683
Standard_B2ms 2 4 683 10 1365
Standard_B4ms 4 16 1365 10 2731
Standard_B8ms 8 32 2731 10 5461
Standard_B12ms 12 48 4097 10 8193
Standard_B16ms 16 64 5461 10 10923
Standard_B20ms 20 80 6827 10 13653
常规用途
Standard_D2ads_v5 2 8 683 10 1365
Standard_D2ds_v4 2 8 683 10 1365
Standard_D4ads_v5 4 16 1365 10 2731
Standard_D4ds_v4 4 16 1365 10 2731
Standard_D8ads_v5 8 32 2731 10 5461
Standard_D8ds_v4 8 32 2731 10 5461
Standard_D16ads_v5 16 64 5461 10 10923
Standard_D16ds_v4 16 64 5461 10 10923
Standard_D32ads_v5 32 128 10923 10 21845
Standard_D32ds_v4 32 128 10923 10 21845
Standard_D48ads_v5 48 192 16384 10 32768
Standard_D48ds_v4 48 192 16384 10 32768
Standard_D64ads_v5 64 256 21845 10 43691
Standard_D64ds_v4 64 256 21845 10 43691
业务关键
Standard_E2ds_v4 2 16 1365 10 2731
Standard_E2ads_v5、Standard_E2ds_v5 2 16 1365 10 2731
Standard_E4ds_v4 4 32 2731 10 5461
Standard_E4ads_v5、Standard_E4ds_v5 4 32 2731 10 5461
Standard_E8ds_v4 8 64 5461 10 10923
Standard_E8ads_v5、Standard_E8ds_v5 8 64 5461 10 10923
Standard_E16ds_v4 16 128 10923 10 21845
Standard_E16ads_v5、Standard_E16ds_v5 16 128 10923 10 21845
Standard_E20ds_v4 20 160 13653 10 27306
Standard_E20ads_v5、Standard_E20ds_v5 20 160 13653 10 27306
Standard_E32ds_v4 32 256 21845 10 43691
Standard_E32ads_v5、Standard_E32ds_v5 32 256 21845 10 43691
Standard_E48ds_v4 48 384 32768 10 65536
Standard_E48ads_v5、Standard_E48ds_v5 48 384 32768 10 65536
Standard_E64ds_v4 64 504 43008 10 86016
Standard_E64ads_v5、Standard_E64ds_v5 64 512 43691 10 87383
Standard_E80ids_v4 80 504 43008 10 86016
Standard_E96ds_v5 96 672 50000 10 100000

当连接数超过限制时，可能会收到以下错误：“错误 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。

innodb_ft_user_stopword_table

innodb_ft_user_stopword_table 是 MySQL 中的服务器参数，用于指定包含 InnoDB 全文搜索自定义非索引字的表的名称。 该表必须与全文索引表位于同一数据库中，且其第一列的类型必须为 VARCHAR。 在 Azure Database for MySQL 灵活服务器中，sql_generate_invisible_primary_key=ON 的默认设置会导致所有没有显式主键的表自动包含一个不可见的主键。 此行为与 innodb_ft_user_stopword_table 的要求冲突，因为不可见的主键会成为表的第一列，使其在全文搜索过程中无法按预期工作。 若要解决此问题，必须在创建自定义非索引字表之前在同一会话中设置 sql_generate_invisible_primary_key=OFF。 例如：

SET sql_generate_invisible_primary_key = OFF;
CREATE TABLE my_stopword_table (
    stopword VARCHAR(50) NOT NULL
);
INSERT INTO my_stopword_table (stopword) VALUES ('and'), ('or'), ('the');

这可确保非索引字表满足 MySQL 的要求，并使自定义非索引字能够正常工作。

不可修改的服务器参数

Azure 门户上的“服务器参数”窗格显示了可修改的服务器参数和不可修改的服务器参数。 不可修改的服务器参数将不可用。 可以在 Azure 门户或 Azure CLI 中使用 init_connect 在会话级别配置不可修改的服务器参数。

相关内容