本文提供在「適用於 MySQL 的 Azure 資料庫」彈性伺服器中設定伺服器參數的考量和指導方針。
附註
本文包含「從屬」一詞的參考，Microsoft 已不再使用。 從軟體中移除該字詞時，我們也會將其從本文中移除。
什麼是伺服器參數？
MySQL 引擎提供許多伺服器參數 (也稱為「變數」)，可用來設定和微調引擎行為。 某些參數可以在執行階段期間動態設定。 其他參數則是靜態的，且在您設定之後需要重新啟動伺服器。
在適用於 MySQL 的 Azure 資料庫 - 彈性伺服器中，您可以使用使用 Azure 入口網站在適用於 MySQL 的 Azure 資料庫 - 彈性伺服器中設定伺服器參數和使用 Azure CLI 在適用於 MySQL 的 Azure 資料庫 - 彈性伺服器中設定伺服器參數來變更不同 MySQL 伺服器參數的值，以符合工作負載的需求。
可設定的伺服器參數
您可以使用伺服器參數來管理適用於 MySQL 的 Azure 資料庫彈性伺服器的設定。 當您建立伺服器時，伺服器參數會設定為預設值和建議值。 Azure 入口網站中的 [伺服器參數] 窗格會同時顯示可修改和不可修改的參數。 不可修改的伺服器參數無法使用。
支援的伺服器參數清單會不斷成長。 您可以使用 Azure 入口網站定期檢視伺服器參數的完整清單，並設定值。
如果您使用入口網站修改靜態伺服器參數，您必須重新啟動伺服器，變更才會生效。 如果您使用自動化指令碼 (透過 Azure Resource Manager 範本、Terraform 或 Azure CLI 之類的工具)，即使您在建立體驗的過程中變更設定，您的指令碼應該有佈建來重新啟動服務以讓設定生效。
如果您想要修改您環境的不可修改伺服器參數，請透過社群意見反應張貼構想，或針對已存在的意見反應投票 (這可協助我們排定優先順序)。
下列各節說明常用更新的伺服器參數限制。 伺服器的計算層和大小 (虛擬核心) 會決定限制。
lower_case_table_names
針對 MySQL 5.7 版，lower_case_table_names 的預設值是適用於 MySQL 的 Azure 資料庫中 - 彈性伺服器中的 1。 雖然可以將支援的值變更為 2，但不允許從 2 還原回 1。 如需變更預設值的協助，請建立支援票證。
針對 MySQL 8.0 以上的版本，您只能在初始化伺服器時設定 lower_case_table_names。 深入了解。 禁止在初始化伺服器之後變更 lower_case_table_names 設定。
MySQL 8.0 版的支援值為適用於 MySQL 的 Azure 資料庫 - 彈性伺服器中的 1 和 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) | 預設值 (位元組) | 最小值 (位元組) | 最大值 (位元組) |
|---|---|---|---|---|---|
| 可高載 | |||||
| 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（標準型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 資料表空間中建立資料表。
適用於 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 參數，請檢查 show global status like 'innodb_buffer_pool_pages_dirty' 的值是否維持在 0 30 秒，以避免重新啟動延遲。
最大連線數量
伺服器的記憶體大小會決定 max_connections 的值。 下表中的實體記憶體大小代表適用於 MySQL 的 Azure 資料庫彈性伺服器上可用的 RAM，以 GB 為單位。
| 計算大小 | 虛擬核心 | 實體記憶體大小 (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（標準型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。
時區
初始部署時，適用於 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 設定為較高的值，則不會很快刪除二進位記錄檔。 這種延遲可能會導致儲存體計費增加。
事件排程器
在適用於 MySQL 的 Azure 資料庫 - 彈性伺服器中，event_scheduler 伺服器參數會管理建立、排程和執行事件。 也就是說，參數會管理由特殊 MySQL Event Scheduler 執行緒根據排程執行的工作。 當 event_scheduler 參數設定為 ON 時，Event Scheduler 執行緒會在 SHOW PROCESSLIST 的輸出中列為精靈程序。
針對 MySQL 5.7 版伺服器，伺服器參數 event_scheduler 會在備份起始時自動「關閉」，而伺服器參數 event_scheduler 會在備份成功完成之後變回「開啟」。 在適用於 MySQL 的 Azure 資料庫 - 彈性伺服器的 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 伺服器參數
下列案例說明在適用於 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) |
| ``` |
| 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。 在適用於 MySQL 的 Azure 資料庫 - 彈性伺服器中，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，在工作階段層級設定不可修改的伺服器參數。
Azure mysql 系統變數
azure_server_name
變數 azure_server_name 提供適用於 MySQL 的 Azure 資料庫 - 彈性伺服器實例的確切伺服器名稱。 當應用程式或腳本需要以程序設計方式擷取其所連接的伺服器主機名時，不需要依賴外部組態，而且可以在 MySQL 內執行下列命令來擷取此變數很有用。
mysql> SHOW GLOBAL VARIABLES LIKE 'azure_server_name';
+-------------------+---------+
| Variable_name | Value |
+-------------------+---------+
| azure_server_name | myflex |
+-------------------+---------+
注意：azure_server_name會穩定地傳回您用來連線到服務的原始伺服器名稱（例如 myflex），無論伺服器是啟用了 HA 或停用了 HA。
logical_server_name
變數 logical_server_name 代表執行「適用於 MySQL 的 Azure 資料庫 - 彈性伺服器」之實例的主機名。 此變數適用於識別服務目前正在執行的主機，協助進行疑難解答和故障轉移監視。 您可以在 MySQL 內執行下列命令來擷取此變數。
mysql> SHOW GLOBAL VARIABLES LIKE 'logical_server_name';
+---------------------+--------------+
| Variable_name | Value |
+---------------------+--------------+
| logical_server_name | myflex |
+---------------------+--------------+
注意：對於啟用HA的伺服器， logical_server_name 變數會反映作為主伺服器之實例的主機名。 針對停用HA的伺服器，值 logical_server_name 會與 azure_server_name 變數相同，因為只有單一實例。