適用於 MySQL 的 Azure 資料庫 - 彈性伺服器中的伺服器參數
適用於： 
適用於 MySQL 的 Azure 資料庫 - 彈性伺服器
本文提供在「適用於 MySQL 的 Azure 資料庫」彈性伺服器中設定伺服器參數的考量和指導方針。
注意
本文包含「從屬」一詞的參考，Microsoft 已不再使用該字詞。 從軟體中移除該字詞時，我們也會將其從本文中移除。
什麼是伺服器變數？
MySQL 引擎提供許多不同的伺服器變數/參數，可用來設定和調整引擎行為。 有些參數可以在執行階段期間動態設定，有些參數則是「靜態」的，需要重新啟動伺服器才能套用。
適用於 MySQL 的 Azure 資料庫彈性伺服器可使用 Azure 入口網站和 Azure CLI 來公開變更各種 MySQL 伺服器參數值的功能，以達到您的工作負載需求。
可設定的伺服器參數
您可以使用伺服器參數來管理適用於 MySQL 的 Azure 資料庫彈性伺服器設定。 當您建立伺服器時，伺服器參數會設定為預設值和建議值。 Azure 入口網站中的伺服器參數刀鋒視窗會同時顯示可修改和不可修改的伺服器參數。 不可修改的伺服器參數會呈現為灰色。
支援的伺服器參數清單會不斷成長。 使用 Azure 入口網站中的 [伺服器參數] 索引標籤，檢視完整清單並設定伺服器參數值。
請參閱下列各節，以深入了解數個經常更新的伺服器參數的限制。 限制取決於伺服器的計算層和大小 (虛擬核心)。
注意
- 如果您使用入口網站修改靜態伺服器參數，您必須重新啟動伺服器，變更才會生效。 如果您使用自動化指令碼 (使用 ARM 範本、Terraform、Azure CLI 等工具)，則您的指令碼應佈建為會重新啟動服務讓設定生效，即使您在建立體驗中變更了設定也一樣。
- 如果您想要修改環境的不可修改伺服器參數，請開啟 UserVoice 項目，或在已有相關意見反應時予以投票，以協助我們排定優先順序。
lower_case_table_names
針對 MySQL 5.7 版，在適用於 MySQL 的 Azure 資料庫彈性伺服器中預設值為 1。 請務必注意，雖然可以將支援的值變更為 2，但不允許從 2 還原為 1。 請連絡我們的支援小組，以取得變更預設值的協助。 針對 MySQL 8.0+ 版，lower_case_table_names 只能在初始化伺服器時設定。 深入了解。 禁止在伺服器初始化之後變更 lower_case_table_names 設定。 針對 MySQL 8.0 版，在適用於 MySQL 的 Azure 資料庫彈性伺服器中預設值為 1。 在適用於 MySQL 的 Azure 資料庫彈性伺服器中MySQL 8.0 版支援的值為 1 和 2。 請連絡我們的支援小組，以取得在伺服器建立期間變更預設值的協助。
innodb_tmpdir
適用於 MySQL 的 Azure 資料庫彈性伺服器中的 innodb_tmpdir 參數是用來定義在重建線上 ALTER TABLE 作業期間建立的暫存排序檔案的目錄。 innodb_tmpdir 的預設值為 /mnt/temp。 此位置會對應至暫存儲存體 SSD，提供 GiB 與各種伺服器計算大小。 此位置非常適合不需要大量空間的作業。
如果需要更多空間，您可以將 innodb_tmpdir 設定為 /app/work/tmpdir。 這會利用適用於 MySQL 的 Azure 資料庫彈性伺服器上可用的儲存體容量。 這對於需要更多暫存儲存體的較大型作業很有用。
請務必注意，相較於預設暫存儲存體 (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
在適用於 MySQL 的 Azure 資料庫彈性伺服器中，一律會啟用二進位記錄 (也就是 log_bin 會設為 [開啟])。 在彈性伺服器中，依預設會將 log_bin_trust_function_creators 設定為 [開啟]。
二進位記錄格式一律為 ROW，而對伺服器的所有連線一律會使用以資料列為基礎的二進位記錄。 使用以資料列為基礎的二進位記錄時不會有安全性問題，且二進位記錄無法中斷，因此您可以安全地允許 log_bin_trust_function_creators 保留為 [開啟]。
如果 [log_bin_trust_function_creators] 設定為 [關閉]，您在嘗試建立觸發程序時可能會收到如下的錯誤：您沒有 SUPER 權限，且二進位記錄已啟用 (您可能想要使用較不安全的 log_bin_trust_function_creators 變數)。
innodb_buffer_pool_size
請檢閱 MySQL 文件 \(英文\)，以深入了解此參數。 下表中的實體記憶體大小 (GB) 代表適用於 MySQL 的 Azure 資料庫彈性伺服器上可用的隨機存取記憶體 (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 資料表空間中建立資料表。
適用於 MySQL 的 Azure 資料庫 彈性伺服器在單一數據檔中支援最多 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 的最大值)。 較大的記錄檔大小有助於提高效能，但缺點是損毀後需要較長的復原時間。 您必須權衡在罕見的損毀後進行復原的時間，與尖峰作業期間的輸送量最大化。 這些因素也可能導致重新啟動時間拉長。 針對適用於 MySQL 的 Azure 資料庫彈性伺服器，您可以將 innodb_log_size 設定為下列任何值 - 256 MB、512 MB、1 GB 或 2 GB。 參數是靜態的，且需要重新啟動。
注意
如果您已將參數 innodb_log_file_size 變更為不使用預設值，請檢查「顯示 'innodb_buffer_pool_pages_dirty' 等全域狀態」的值是否維持在 0 達 30 秒之久，以免重新啟動發生延遲。
max_connections
max_connection 的值取決於伺服器的記憶體大小。 下表中的實體記憶體大小 (GB) 代表適用於 MySQL 的 Azure 資料庫彈性伺服器上可用的隨機存取記憶體 (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 設定為 [關閉]，將會中斷複寫。 如果您有讀取複本，建議您將參數保持設定為 [開啟]。
time_zone
初始部署時，適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體會包含時區資訊的系統資料表，但不會填入這些資料表。 時區資料表可藉由從 MySQL 命令列或 MySQL Workbench 等工具呼叫 mysql.az_load_timezone 預存程序來填入。 請參閱 Azure 入口網站或 Azure CLI 文章，以了解如何呼叫預存程序，以及設定全域或工作階段層級的時區。
binlog_expire_logs_seconds
在適用於 MySQL 的 Azure 資料庫彈性伺服器中，此參數會指定服務在清除二進位記錄檔之前等候的秒數。
二進位記錄包含描述資料庫變更的「事件」，例如資料表建立作業或對資料表資料的變更。 此外也包含可能已進行變更之陳述式的事件。 二進位記錄檔主要用於兩個用途：複寫和資料復原作業。 一般而言，只要控制代碼沒有服務、備份或複本集，就會清除二進位記錄檔。 如果有多個複本，二進位記錄檔會等候最慢的複本讀取變更，然後再清除。 如果您想要將二進位記錄保存一段時間，可以設定參數 binlog_expire_logs_seconds。 如果 binlog_expire_logs_seconds 設定為 0 (此為預設值)，則會在釋放二進位記錄的控制代碼時立即清除。 如果 binlog_expire_logs_seconds > 0，則會等到設定的秒數經過後才清除。 針對適用於 MySQL 的 Azure 資料庫彈性伺服器，備份和讀取二進位檔案的複本清除等受控功能會在內部處理。 從適用於 MySQL 的 Azure 資料庫彈性伺服器複寫資料時，必須在主要複本中設定此參數，以避免在複本從主要複本讀取變更之前清除二進位記錄。 如果您將 binlog_expire_logs_seconds 設定為較高的值，則二進位記錄將不會及時清除，而可能會導致儲存體計費增加。
event_scheduler
在適用於 MySQL 的 Azure 資料庫彈性伺服器中，event_schedule 伺服器參數會管理建立、排程和執行事件，也就是工作根據排程執行，並且依據特殊事件排程器執行緒執行。 當 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 伺服器參數
下列案例說明在適用於 MySQL 的 Azure 資料庫彈性伺服器中使用 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)
若要在適用於 MySQL 的 Azure 資料庫彈性伺服器中設定 event_scheduler 伺服器參數，請執行下列步驟：
在 Azure 入口網站中，瀏覽至您適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體，然後在 [設定] 底下，選取 [伺服器參數]。
在 [伺服器參數] 刀鋒視窗上，搜尋
event_scheduler，在 [值] 下拉式清單中，選取 [開啟]，然後選取 [儲存]。注意
動態伺服器參數組態變更將會部署，而不會重新啟動。
然後，若要建立事件，請連線到適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體，然後執行下列 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 伺服器參數設定為 [關閉]。 如果發生這種情況，當容錯移轉完成時，請設定 參數以將值設定為 [開啟]。
不可修改伺服器參數
Azure 入口網站上的伺服器參數刀鋒視窗會同時顯示可修改和不可修改的伺服器參數。 不可修改的伺服器參數會呈現為灰色。如果您想要在工作階段層級設定不可修改的伺服器參數，請參閱 Azure 入口網站或 Azure CLI 一文，以使用 init_connect 在連線層級設定參數。
下一步
- 如何設定 Azure 入口網站中的伺服器參數
- 如何設定 Azure CLI 中的伺服器參數