Freigeben über

Serverparameter in Azure Database for MySQL – Flexibler Server

  • Artikel

Dieser Artikel enthält Überlegungen und Anleitungen zur Konfiguration von Serverparametern in Azure Database for MySQL – Flexibler Server.

Hinweis

Dieser Artikel enthält Verweise auf den Begriff Slave, den Microsoft nicht mehr verwendet. Sobald der Begriff aus der Software entfernt wurde, wird er auch aus diesem Artikel entfernt.

Was sind Serverparameter?

Das MySQL-Modul stellt viele Serverparameter (auch als Variablen bezeichnet) bereit, die Sie zum Konfigurieren und Optimieren des Modulverhaltens verwenden können. Einige Parameter können während der Laufzeit dynamisch festgelegt werden. Andere sind statisch und erfordern einen Serverneustart, nachdem Sie sie festgelegt haben.

In Azure Database for MySQL – Flexibler Server können Sie den Wert verschiedener MySQL-Serverparameter entsprechend den Anforderungen Ihrer Workload ändern, indem Sie die Anleitungen unter Konfigurieren von Serverparametern in Azure Database for MySQL – Flexibler Server mithilfe des Azure-Portals und Konfigurieren von Serverparametern in Azure Database for MySQL – Flexibler Server mithilfe der Azure CLI verwenden.

Konfigurierbare Serverparameter

Sie können die Konfiguration einer Instanz von Azure Database for MySQL – Flexibler Server über Serverparameter verwalten. Die Serverparameter werden beim Erstellen des Servers mit Standardwerten und empfohlenen Werten konfiguriert. Auf dem Blatt Serverparameter im Azure-Portal werden sowohl änderbare als auch nicht änderbare Parameter angezeigt. Die nicht änderbaren Serverparameter sind deaktiviert.

Die Liste der unterstützten Serverparameter wächst ständig. Sie können das Azure-Portal verwenden, um die vollständige Liste der Serverparameter regelmäßig anzuzeigen und die Werte zu konfigurieren.

Wenn Sie einen statischen Serverparameter über das Portal ändern, müssen Sie den Server neu starten, damit die Änderungen übernommen werden. Falls Sie Automatisierungsskripts verwenden (mit Tools wie Azure Resource Manager-Vorlagen, Terraform, Azure CLI usw.), sollte Ihr Skript einen Neustart des Dienstes vorsehen, damit die Einstellungen auch dann wirksam werden, wenn Sie die Konfigurationen im Rahmen der Erstellung ändern.

Wenn Sie einen nicht änderbaren Serverparameter für Ihre Umgebung ändern möchten, posten Sie eine Idee über Communityfeedback oder geben Ihre Stimme ab, wenn bereits Feedback gegeben wurde. So helfen Sie uns bei der Priorisierung.

In den folgenden Abschnitten werden die Grenzwerte der häufig aktualisierten Serverparameter beschrieben. Die Computeebene und die Größe (vCores) des Servers bestimmen die Grenzwerte.

lower_case_table_names

Für MySQL Version 5.7 lautet der Standardwert lower_case_table_names in Azure Database for MySQL – Flexibler Server 1. Obwohl es möglich ist, den unterstützten Wert auf 2 zu ändern, ist das Zurücksetzen von 2 zurück auf 1 nicht zulässig. Um Unterstützung beim Ändern des Standardwerts zu erhalten, öffnen Sie ein Supportticket.

Für MySQL Version 8.0+ können Sie lower_case_table_names nur konfigurieren, wenn Sie den Server initialisieren. Weitere Informationen Das Ändern der Einstellung lower_case_table_names nach der Initialisierung des Servers ist unzulässig.

Die unterstützten Werte für MySQL Version 8.0 sind 1 und 2 in Azure Database for MySQL – Flexibler Server. Der Standardwert ist 1. Wenn Sie während der Servererstellung Hilfe beim Ändern des Standardwerts benötigen, öffnen Sie ein Supportticket.

innodb_tmpdir

Mit dem innodb_tmpdir-Parameter in Azure Database for MySQL – Flexibler Server definieren Sie das Verzeichnis für temporäre Sortierdateien, die während ALTER TABLE-Onlinevorgängen erstellt wurden und neu erstellt werden.

Der Standardwert von innodb_tmpdir ist /mnt/temp. Dieser Speicherort entspricht dem für jede Computegröße auf dem Server verfügbaren temporären SSD-Speicher in Gibibytes (GiB). Dieser Speicherort eignet sich ideal für Vorgänge, die keinen großen Speicherplatz benötigen.

Wenn Sie mehr Platz benötigen, können Sie innodb_tmpdir auf /app/work/tmpdir festlegen. Diese Einstellung verwendet die verfügbare Speicherkapazität Ihrer Instanz von Azure Database for MySQL – Flexibler Server. Diese Einstellung kann für größere Vorgänge nützlich sein, die mehr temporären Speicher erfordern.

Beachten Sie, dass die Verwendung von /app/work/tmpdir die Leistung im Vergleich zum /mnt/temp-Wert des temporären Standardspeichers (SSD) verlangsamt. Treffen Sie Ihre Entscheidung auf der Grundlage der spezifischen Anforderungen der jeweiligen Vorgänge.

Die für innodb_tmpdir bereitgestellten Informationen gelten für die Parameter innodb_temp_tablespaces_dir, tmpdir und slave_load_tmpdir, wobei:

  • Der Standardwert /mnt/temp ist üblich.
  • Das alternative Verzeichnis /app/work/tmpdir steht für die Konfiguration erhöhter temporärer Speicher zur Verfügung, wobei ein Kompromiss in der Leistung auf der Grundlage bestimmter betrieblicher Anforderungen besteht.

log_bin_trust_function_creators

In Azure Database for MySQL – Flexibler Server sind binäre Protokolle immer aktiviert (d. h., log_bin ist auf ON festgelegt). Der log_bin_trust_function_creators-Parameter ist auf flexible Server standardmäßig auf ON festgelegt.

Das Format für binäre Protokollierung ist immer ROW und für Verbindungen mit dem Server wird immer die zeilenbasierte binäre Protokollierung verwendet. Bei der zeilenbasierten binären Protokollierung gibt es keine Sicherheitsprobleme, und die binäre Protokollierung kann nicht unterbrochen werden, sodass log_bin_trust_function_creators sicher auf ON gesetzt bleiben kann.

Wenn log_bin_trust_function_creators auf OFF festgelegt ist und Sie versuchen, Trigger zu erstellen, erhalten Sie möglicherweise eine Fehlermeldung wie „Sie verfügen nicht über die SUPER-Berechtigung, und die binäre Protokollierung ist aktiviert (es kann ratsam sein, die weniger sichere Variable log_bin_trust_function_creators zu verwenden).“

innodb_buffer_pool_size

Weitere Informationen zum Parameter innodb_buffer_pool_size finden Sie in der MySQL-Dokumentation.

Die Größe des physischen Speichers in der folgenden Tabelle stellt den verfügbaren Arbeitsspeicher (Random Access Memory, RAM) Ihrer Instanz von Azure Database for MySQL – Flexibler Server in Gigabyte (GB) dar.

Tarif V-Kerne Größe des physischen Speichers (GB) Standardwert (Bytes) Mindestwert (Bytes) Höchstwert (Bytes)
Burstfähig (B1s) 1 1 134217728 33554432 268435456
Burstfähig (B1ms) 1 2 536870912 134217728 1073741824
Burstfähig (B2s) 2 4 2147483648 134217728 2147483648
Burstfähig (B2ms) 2 8 4294967296 134217728 5368709120
Burstfähig 4 16 12884901888 134217728 12884901888
Burstfähig 8 32 25769803776 134217728 25769803776
Burstfähig 12 48 51539607552 134217728 51539607552
Burstfähig 16 64 2147483648 134217728 2147483648
Burstfähig 20 80 64424509440 134217728 64424509440
Universell 2 8 4294967296 134217728 5368709120
Universell 4 16 12884901888 134217728 12884901888
Universell 8 32 25769803776 134217728 25769803776
Universell 16 64 51539607552 134217728 51539607552
Universell 32 128 103079215104 134217728 103079215104
Universell 48 192 154618822656 134217728 154618822656
Universell 64 256 206158430208 134217728 206158430208
Unternehmenskritisch 2 16 12884901888 134217728 12884901888
Unternehmenskritisch 4 32 25769803776 134217728 25769803776
Unternehmenskritisch 8 64 51539607552 134217728 51539607552
Unternehmenskritisch 16 128 103079215104 134217728 103079215104
Unternehmenskritisch 20 160 128849018880 134217728 128849018880
Unternehmenskritisch 32 256 206158430208 134217728 206158430208
Unternehmenskritisch 48 384 309237645312 134217728 309237645312
Unternehmenskritisch 64 504 405874409472 134217728 405874409472

innodb_file_per_table

MySQL speichert die InnoDB-Tabelle in verschiedenen Tabellenbereichen, basierend auf der Konfiguration, die Sie während der Tabellenerstellung angegeben haben. Der Systemtabellenbereich ist der Speicherbereich für das InnoDB-Datenwörterbuch. Ein file-per-table-Tabellenbereich enthält die Daten und Indizes für eine einzelne InnoDB-Tabelle und wird im Dateisystem in einer eigenen Datendatei gespeichert. Der Serverparameter innodb_file_per_table steuert dieses Verhalten.

Durch Festlegen von innodb_file_per_table auf OFF werden Tabellen von InnoDB im Systemtabellenbereich erstellt. Andernfalls werden die Tabellen im Tabellen-Tabellenbereich erstellt.

Azure Database for MySQL – Flexibler Server unterstützt bis zu 8 Terabytes (TB) in einer einzelnen Datendatei. Wenn die Datenbankgröße 8 TB überschreitet, sollten Sie die Tabelle im Tabellenbereich innodb_file_per_table erstellen. Wenn eine einzelne Tabelle größer als 8 TB ist, müssen Sie die Partitionstabelle verwenden.

innodb_log_file_size

Der Wert innodb_log_file_size ist die Größe in Bytes jeder Protokolldatei in einer Protokollgruppe. Die kombinierte Größe der Protokolldateien (innodb_log_file_size * innodb_log_files_in_group) darf einen Maximalwert von etwas weniger als 512 GB nicht überschreiten.

Eine größere Protokolldateigröße ist für die Leistung besser, hat jedoch den Nachteil, dass die Wiederherstellungszeit nach einem Absturz hoch ist. Sie müssen zwischen der Wiederherstellungszeit im seltenen Fall eines Absturzes und der Maximierung des Durchsatzes während Spitzenvorgängen abwägen. Eine größere Protokolldatei kann auch zu längeren Neustartzeiten führen.

Sie können innodb_log_size für Azure Database for MySQL – Flexibler Server mit diesen Werten konfigurieren: 256 Megabytes (MB), 512 MB, 1 GB oder 2 GB. Der Parameter ist statisch und erfordert einen Neustart.

Hinweis

Wenn Sie den innodb_log_file_size-Parameter von der Standardeinstellung geändert haben, überprüfen Sie, ob der Wert von show global status like 'innodb_buffer_pool_pages_dirty' 30 Sekunden lang auf 0 bleibt, um Neustartverzögerungen zu vermeiden.

max_connections

Die Arbeitsspeichergröße des Servers bestimmt den Wert von max_connections. Die Größe des physischen Speichers in der folgenden Tabelle stellt den verfügbaren Arbeitsspeicher (Random Access Memory, RAM) Ihrer Instanz von Azure Database for MySQL – Flexibler Server in Gigabyte dar.

Tarif V-Kerne Größe des physischen Speichers (GB) Standardwert Mindestwert Höchstwert
Burstfähig (B1s) 1 1 85 10 171
Burstfähig (B1ms) 1 2 171 10 341
Burstfähig (B2s) 2 4 341 10 683
Burstfähig (B2ms) 2 4 683 10 1365
Burstfähig 4 16 1365 10 2731
Burstfähig 8 32 2731 10 5461
Burstfähig 12 48 4097 10 8193
Burstfähig 16 64 5461 10 10923
Burstfähig 20 80 6827 10 13653
Allgemeiner Zweck 2 8 683 10 1365
Universell 4 16 1365 10 2731
Universell 8 32 2731 10 5461
Universell 16 64 5461 10 10923
Universell 32 128 10923 10 21845
Universell 48 192 16384 10 32768
Universell 64 256 21845 10 43691
Unternehmenskritisch 2 16 1365 10 2731
Unternehmenskritisch 4 32 2731 10 5461
Unternehmenskritisch 8 64 5461 10 10923
Unternehmenskritisch 16 128 10923 10 21845
Unternehmenskritisch 20 160 13653 10 27306
Unternehmenskritisch 32 256 21845 10 43691
Unternehmenskritisch 48 384 32768 10 65536
Unternehmenskritisch 64 504 43008 10 86016

Wenn Verbindungen den Grenzwert übersteigen, erhalten Sie möglicherweise den folgenden Fehler: „FEHLER 1040 (08004): Zu viele Verbindungen.“

Erstellen neuer Clientverbindungen in MySQL bedarf Zeit. Nachdem Sie diese Verbindungen hergestellt haben, belegen sie Datenbankressourcen, auch wenn sie im Leerlauf sind. Die meisten Anwendungen fordern viele kurzlebige Verbindungen an, was diese Situation erschwert. Das Ergebnis sind weniger Ressourcen, die für ihre tatsächliche Workload verfügbar sind, was zu verringerter Leistung führt.

Ein Verbindungspooler, der Verbindungen im Leerlauf reduziert und vorhandene Verbindungen wiederverwendet, hilft Ihnen dabei, dieses Problem zu vermeiden. Für eine optimale Erfahrung empfehlen wir, dass Sie einen Verbindungsspooler wie ProxySQL verwenden, um Verbindungen effizient zu verwalten. Weitere Informationen zum Einrichten von ProxySQL finden Sie in diesem Blogbeitrag.

Hinweis

ProxySQL ist ein Open Source-Communitytool. Es wird von Microsoft bestmöglich unterstützt. Wenden Sie sich an den ProxySQL-Produktsupport, um Unterstützung für die Produktion mit autoritativer Anleitung zu erhalten.

innodb_strict_mode

Wenn ein Fehler wie „Zeile zu groß (> 8126)“ angezeigt wird, sollten Sie den Parameter innodb_strict_mode deaktivieren. Dieser Parameter kann nicht global auf der Serverebene geändert werden, da die Daten bei Überschreitung einer Zeilendatengröße von 8 000 ohne Fehlermeldung gekürzt werden. Diese Kürzung kann zu potenziellem Datenverlust führen. Es wird empfohlen, das Schema so zu ändern, dass es der Seitengrößenbeschränkung entspricht.

Sie können diesen Parameter mithilfe von init_connect auf Sitzungsebene festlegen. Weitere Informationen finden Sie unter Festlegen nicht modifizierbarer Serverparameter.

Hinweis

Wenn Sie über einen Lesereplikatserver verfügen, wird die Replikation unterbrochen, wenn Sie innodb_strict_mode auf einem Quellserver auf Sitzungsebene auf OFF festlegen. Wir empfehlen, den Parameter auf ON zu belassen, wenn Sie über Lesereplikate verfügen.

time_zone

Bei der ersten Bereitstellung enthält eine Instanz von Azure Database for MySQL – Flexibler Server Systemtabellen für Zeitzoneninformationen, die jedoch nicht gefüllt sind. Sie können die Zeitzonentabellen durch Aufrufen der gespeicherten Prozedur mysql.az_load_timezone über ein Tool wie die MySQL-Befehlszeile oder MySQL Workbench auffüllen. Informationen zum Aufrufen der gespeicherten Prozedur und zum Festlegen der globalen Zeitzonen oder Zeitzonen auf Sitzungsebene finden Sie in den Artikeln für das Azure-Portal und die Azure CLI.

binlog_expire_logs_seconds

In Azure Database for MySQL – Flexibler Server gibt der binlog_expire_logs_seconds-Parameter die Anzahl der Sekunden an, die der Dienst wartet, bevor die binäre Protokolldatei gelöscht wird.

Das binäre Protokoll enthält Ereignisse, die Datenbankänderungen beschreiben, z. B. Tabellenerstellungsvorgänge oder Änderungen an Tabellendaten. Das binäre Protokoll enthält auch Ereignisse für Anweisungen, die möglicherweise Änderungen vorgenommen haben. Das binäre Protokoll wird hauptsächlich für zwei Zwecke verwendet: für Replikations- und Datenwiederherstellungsvorgänge.

In der Regel werden die binären Protokolle gelöscht, sobald das Handle von Dienst, Sicherung oder Replikatgruppe freigegeben wird. Wenn es mehrere Replikate gibt, warten die Binärprotokolle, bis das langsamste Replikat die Änderungen gelesen hat, bevor sie gelöscht werden.

Wenn binäre Protokolle länger beibehalten werden sollen, können Sie den Parameter binlog_expire_logs_secondskonfigurieren. Wenn binlog_expire_logs_seconds auf den Standardwert 0 festgelegt ist, wird ein binäres Protokoll gelöscht, sobald das Handle für das Binärprotokoll freigegeben wird. Wenn der Wert binlog_expire_logs_seconds größer als 0 ist, wird das binäre Protokoll nach der konfigurierten Anzahl von Sekunden gelöscht.

Azure Database for MySQL – Flexibler Server behandelt verwaltete Features wie das Löschen von Binärdateien aus Sicherungen und Lesereplikaten intern. Wenn Sie die Daten aus Azure Database for MySQL – Flexibler Server replizieren, muss dieser Parameter am primären Speicherort festgelegt werden, um zu vermeiden, dass binäre Protokolle gelöscht werden, bevor das Replikat die Änderungen des primären Speicherorts gelesen hat. Wenn Sie binlog_expire_logs_seconds auf einen höheren Wert festlegen, werden die binären Protokolle nicht bald genug gelöscht. Diese Verzögerung kann zu einer Erhöhung der Abrechnung für Speicher führen.

event_scheduler

In der Azure Database for MySQL – Flexibler Server verwaltet der event_scheduler-Serverparameter das Erstellen, Planen und Ausführen von Ereignissen. Das heißt, der Parameter verwaltet Aufgaben, die gemäß einem Zeitplan von einem speziellen MySQL Event Scheduler-Thread ausgeführt werden. Wenn der event_scheduler-Parameter auf ON festgelegt ist, wird der Event Scheduler-Thread in der Ausgabe von SHOW PROCESSLIST als Daemon-Prozess aufgeführt.

Bei MySQL-Servern mit Version 5.7 wird der Serverparameter event_scheduler automatisch deaktiviert, wenn die Sicherung initiiert wird. Außerdem wird der Serverparameter event_scheduler nach erfolgreichem Abschluss der Sicherung wieder auf „EIN“ zurückgesetzt. In MySQL Version 8.0 für Azure Database for MySQL – Flexibler Server ist „event_scheduler“ während Sicherungen nicht betroffen. Um einen reibungsloseren Betrieb sicherzustellen, empfiehlt es sich, Ihre MySQL 5.7-Server mithilfe eines Hauptversionsupgrades auf Version 8.0 zu aktualisieren.

Sie können Ereignisse mit der folgenden SQL-Syntax erstellen und planen:

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>;

Weitere Informationen zum Erstellen eines Ereignisses finden Sie in der folgenden Dokumentation zum Event Scheduler im MySQL-Referenzhandbuch:

Konfigurieren des event_scheduler-Serverparameters

Das folgende Szenario veranschaulicht eine Möglichkeit zur Verwendung des event_scheduler-Parameters in Azure Database for MySQL – Flexibler Server.

Das folgende Beispiel, eine einfache Tabelle, soll das Szenario verdeutlichen:

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>;

So führen Sie eine unbegrenzte stündliche SQL-Anweisung:

CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 HOUR
COMMENT 'Comment'
DO
<your statement>;

So führen Sie eine unbegrenzte tägliche SQL-Anweisung:

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>;

Begrenzungen

Bei Servern mit konfigurierter Hochverfügbarkeit ist es bei einem Failover möglich, dass der event_scheduler-Serverparameter auf OFF festgelegt ist. Wenn dies der Fall ist, konfigurieren Sie nach Abschluss des Failovers den Parameter, um den Wert auf ON festzulegen.

Nicht änderbare Serverparameter

Auf dem Blatt Serverparameter im Azure-Portal werden sowohl änderbare als auch nicht änderbare Serverparameter angezeigt. Die nicht änderbaren Serverparameter sind deaktiviert. Sie können einen nicht modifizierbaren Serverparameter auf Sitzungsebene konfigurieren, indem Sie init_connect im Azure-Portal oder in der Azure CLI verwenden.

Zugehöriger Inhalt