適用於 MySQL 的 Azure 資料庫 - 彈性伺服器中的伺服器參數
適用於：
適用於 MySQL 的 Azure 資料庫 - 彈性伺服器
本文提供在 適用於 MySQL 的 Azure 資料庫 - 彈性伺服器中設定伺服器參數的考慮和指導方針。
注意
本文包含從屬一詞的參考，Microsoft不再使用。 從軟體中移除該字詞時，我們也會將其從本文中移除。
什麼是伺服器參數？
MySQL 引擎提供許多 伺服器參數 （也稱為 變數），可用來設定和微調引擎行為。 某些參數可以在運行時間期間動態設定。 其他則是靜態的，而且在您設定伺服器之後需要重新啟動伺服器。
在 適用於 MySQL 的 Azure 資料庫 - 彈性伺服器中，您可以使用 Azure 入口網站 和 Azure CLI 來變更各種 MySQL 伺服器參數的值，以符合工作負載的需求。
可設定的伺服器參數
您可以使用伺服器參數來管理 適用於 MySQL 的 Azure 資料庫 彈性伺服器的組態。 當您建立伺服器時，伺服器參數會設定為預設值和建議的值。 Azure 入口網站 中的 [伺服器參數] 窗格會顯示可修改和不可修改的參數。 無法使用不可修改的伺服器參數。
支援的伺服器參數清單會不斷成長。 您可以使用 Azure 入口網站 定期檢視伺服器參數的完整清單並設定值。
如果您使用入口網站修改靜態伺服器參數，您必須重新啟動伺服器，變更才會生效。 如果您使用自動化腳本（透過 Azure Resource Manager 範本、Terraform 或 Azure CLI 之類的工具），您的腳本應該有布建來重新啟動服務，讓設定生效，即使您在建立體驗中變更設定。
如果您想要修改您環境的不可修改伺服器參數，請 透過社群意見反應張貼想法，或投票是否已經存在意見反應（這可協助我們排定優先順序）。
下列各節說明常用更新的伺服器參數限制。 伺服器的計算層和大小 （虛擬核心） 會決定限制。
lower_case_table_names
針對 MySQL 5.7 版，預設值lower_case_table_names為 1 適用於 MySQL 的 Azure 資料庫 - 彈性伺服器。 雖然可以支援的值變更為 2，但不允許從 2 還原回 1 。 如需變更預設值的協助， 請建立支援票證。
針對 MySQL 8.0 版以上 ，您 lower_case_table_names 只能在初始化伺服器時進行設定。 深入了解。 禁止在初始化伺服器之後變更 lower_case_table_names 設定。
MySQL 8.0 1 版的支援值為 適用於 MySQL 的 Azure 資料庫 2 - 彈性伺服器。 預設值是 1。 如需在建立伺服器期間變更預設值的協助， 請建立支援票證。
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 設定為 ON）。 log_bin_trust_function_creators參數預設會在彈性伺服器中設定為 ON 。
二進位記錄格式一律 ROW為 ，而且伺服器的連接一律使用數據列型二進位記錄。 使用資料列型二進位記錄時，安全性問題不存在，而且二進位記錄無法中斷，因此您可以安全地允許 log_bin_trust_function_creators 保持為 ON。
如果 log_bin_trust_function_creators 設定為 OFF ，而且您嘗試建立觸發程式，您可能會收到類似如下的錯誤：「您沒有 SUPER 許可權，而且已啟用二進位記錄（您可能想要使用較不安全 log_bin_trust_function_creators 的變數）。
innodb_buffer_pool_size
若要了解 innodb_buffer_pool_size 參數，請檢閱 MySQL 檔。
下表中的物理記憶體大小代表您 適用於 MySQL 的 Azure 資料庫 彈性伺服器上的可用隨機存取記憶體 （RAM），以 GB 為單位。
| 定價層 | 虛擬核心 | 實體記憶體大小 （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 資料字典的儲存區域。 每個 數據表的檔案數據表空間 包含單一 InnoDB 資料表的數據和索引，並且儲存在檔案系統中自己的數據檔中。 innodb_file_per_table伺服器參數會控制此行為。
將 innodb_file_per_table 設定為 OFF 會導致 InnoDB 在系統資料表空間中建立資料表。 否則，InnoDB 會在 file-per-table 資料表空間中建立資料表。
適用於 MySQL 的 Azure 資料庫 - 彈性伺服器在單一數據檔中最多支援 8 TB（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（MB）、512 MB、1 GB 或 2 GB for 適用於 MySQL 的 Azure 資料庫 - 彈性伺服器。 參數是靜態的，且需要重新啟動。
注意
如果您已從預設值變更 innodb_log_file_size 參數，請檢查的值 show global status like 'innodb_buffer_pool_pages_dirty' 是否維持在 0 30 秒，以避免重新啟動延遲。
max_connections
伺服器的記憶體大小決定的值 max_connections。 下表中的物理記憶體大小代表您 適用於 MySQL 的 Azure 資料庫 彈性伺服器上的可用 RAM，以 GB 為單位。
| 定價層 | 虛擬核心 | 實體記憶體大小 （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
初始部署時，適用於 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 參數。 如果 binlog_expire_logs_seconds 設定為的預設值 0，則會在釋放二進位記錄檔的句柄后立即刪除。 如果的值 binlog_expire_logs_seconds 大於 0，則會在設定的秒數之後刪除二進位記錄檔。
適用於 MySQL 的 Azure 資料庫 - 彈性伺服器會在內部處理受控功能，例如備份和讀取二進位檔刪除。 當您從 適用於 MySQL 的 Azure 資料庫 - 彈性伺服器複寫資料輸出時，此參數必須在主要複本中設定，以避免在複本從主要複本的變更讀取之前刪除二進位記錄。 如果您設定 binlog_expire_logs_seconds 為較高的值，則不會很快刪除二進位記錄檔。 這種延遲可能會導致記憶體計費增加。
event_scheduler
在 適用於 MySQL 的 Azure 資料庫 - 彈性伺服器中，event_scheduler伺服器參數會管理建立、排程和執行事件。 也就是說，參數會管理由特殊 MySQL 事件排程器線程根據排程執行的工作。 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 伺服器參數
下列案例說明在 適用於 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());若要檢視事件排程器詳細數據，請執行下列 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 入口網站 中的 [伺服器參數] 窗格會顯示可修改和不可修改的伺服器參數。 無法使用不可修改的伺服器參數。 您可以在工作階段層級使用 init_connect Azure 入口網站 或 Azure CLI 來設定不可修改的伺服器參數。