Teilen über

Serverparameter in Azure Database for MySQL

  • Artikel

GILT FÜR: Azure-Datenbank für MySQL - Single Server

Wichtig

Azure Database for MySQL Single Server wird eingestellt. Es wird dringend empfohlen, ein Upgrade auf Azure Database for MySQL Flexible Server auszuführen. Weitere Informationen zum Migrieren zu Azure Database for MySQL Flexible Server finden Sie unter Was geschieht mit Azure Database for MySQL Single Server?

Dieser Artikel enthält Überlegungen und Richtlinien zur Konfiguration von Serverparametern in Azure Database for MySQL.

Was sind Serverparameter?

Die MySQL-Engine bietet viele verschiedene Servervariablen und -parameter, die Sie zur Konfiguration und Optimierung des Engine-Verhaltens verwenden. Einige der Parameter können dynamisch während der Laufzeit festgelegt werden, während andere statisch sind und einen Neustart des Servers erfordern, damit sie angewendet werden.

Azure Database for MySQL ermöglicht es, den Wert verschiedener MySQL-Serverparameter mit dem Azure-Portal, mit der Azure CLI und mit PowerShell zu ändern, um den Anforderungen Ihrer Workload zu entsprechen.

Konfigurierbare Serverparameter

Die Liste der unterstützten Serverparameter wächst ständig. Verwenden Sie im Azure-Portal die Registerkarte „Serverparameter“, um die vollständige Liste anzuzeigen und Serverparameterwerte zu konfigurieren.

In den folgenden Abschnitten erfahren Sie mehr über die Grenzwerte der verschiedenen häufig aktualisierten Serverparameter. Die Grenzwerte werden durch den Tarif und die Anzahl der virtuellen Kerne des Servers bestimmt.

Threadpools

MySQL weist traditionell einen Thread für jede Clientverbindung zu. Wenn die Zahl der gleichzeitigen Benutzer steigt, sinkt die Leistung entsprechend. Viele aktive Threads können die Leistung aufgrund von erhöhtem Kontextwechsel, Threadkonflikten und ungeeignetem Speicherort für CPU-Caches erheblich beeinträchtigen.

Threadpools, eine serverseitige Funktion, die sich vom Verbindungspooling unterscheiden, maximieren die Leistung, indem ein dynamischer Pool von Workerthreads eingeführt wird. Sie verwenden dieses Feature, um die Anzahl der aktiven Threads zu begrenzen, die auf dem Server ausgeführt werden, und den Threadchurn zu minimieren. Dadurch wird sichergestellt, dass der Server bei einer großen Anzahl von Verbindungen nicht an seine Arbeitsspeicher-Grenzen stößt. Threadpools sind am effizientesten für kurze Abfragen und CPU-intensive Workloads, z. B. OLTP-Workloads.

Weitere Informationen finden Sie unter Einführung von Threadpools in Azure Database for MySQL.

Hinweis

Threadpools werden für MySQL 5.6 nicht unterstützt.

Konfigurieren des Threadpools

Aktualisieren Sie zum Aktivieren des Threadpools den thread_handling-Serverparameter auf pool-of-threads. Standardmäßig ist dieser Parameter auf one-thread-per-connection festgelegt, was bedeutet, dass MySQL für jede neue Verbindung einen neuen Thread erstellt. Hierbei handelt es sich um einen statischen Parameter, der einen Serverneustart erfordert, damit er wirksam wird.

Sie können auch die maximale und minimale Anzahl von Threads im Pool konfigurieren, indem Sie die folgenden Serverparameter festlegen:

  • thread_pool_max_threads: Dieser Wert begrenzt die Anzahl der Threads im Pool.
  • thread_pool_min_threads: Dieser Wert legt die Anzahl der Threads fest, die auch nach dem Beenden von Verbindungen reserviert werden.

Um Leistungsprobleme bei kurzen Abfragen im Threadpool zu verbessern, können Sie Batchausführung aktivieren. Anstatt unmittelbar nach dem Ausführen einer Abfrage zum Threadpool zurückzukehren, bleiben Threads für kurze Zeit aktiv, um auf die nächste Abfrage über diese Verbindung zu warten. Der Thread führt die Abfrage dann schnell aus, und wenn diese abgeschlossen ist, wartet der Thread auf die nächste Abfrage. Dieser Prozess wird so lange fortgesetzt, bis die verstrichene Gesamtzeit einen Schwellenwert überschreitet.

Sie bestimmen das Verhalten der Batchausführung mithilfe der folgenden Serverparameter:

  • thread_pool_batch_wait_timeout: Dieser Wert gibt die Zeit an, die ein Thread auf die Verarbeitung einer anderen Abfrage wartet.
  • thread_pool_batch_max_time: Dieser Wert bestimmt die maximale Zeit, die ein Thread den Zyklus der Abfrageausführung und des Wartens auf die nächste Abfrage wiederholt.

Wichtig

Aktivieren Sie den Threadpool erst in der Produktion, nachdem Sie ihn getestet haben.

log_bin_trust_function_creators

In Azure Database for MySQL sind binäre Protokolle immer aktiviert (der log_bin-Parameter ist auf ON festgelegt). Wenn Sie Trigger verwenden möchten, erhalten Sie eine Fehlermeldung ähnlich der folgenden: Sie verfügen nicht über die SUPER-Berechtigung und die binäre Protokollierung ist aktiviert (Sie könnten die weniger sichere Variable log_bin_trust_function_creators verwenden).

Das Format für binäre Protokollierung ist immer ROW (Zeile), und für alle Verbindungen mit dem Server wird immer zeilenbasierte binäre Protokollierung verwendet. Zeilenbasierte binäre Protokollierung trägt zur Aufrechterhaltung der Sicherheit bei, und binäre Protokollierung kann nicht unterbrochen werden, sodass Sie log_bin_trust_function_creators sicher auf TRUE festlegen können.

innodb_buffer_pool_size

Weitere Informationen zu diesem Parameter finden Sie in der MySQL-Dokumentation.

Server für den Speichertyp „Universell v1“ (unterstützt bis zu 4 TB)

Preisstufe vCore(s) Standardwert (Bytes) Mindestwert (Bytes) Höchstwert (Bytes)
Basic 1 872415232 134217728 872415232
Basic 2 2684354560 134217728 2684354560
Universell 2 3758096384 134217728 3758096384
Universell 4 8053063680 134217728 8053063680
Universell 8 16106127360 134217728 16106127360
Universell 16 32749125632 134217728 32749125632
Universell 32 66035122176 134217728 66035122176
Universell 64 132070244352 134217728 132070244352
Arbeitsspeicheroptimiert 2 7516192768 134217728 7516192768
Arbeitsspeicheroptimiert 4 16106127360 134217728 16106127360
Arbeitsspeicheroptimiert 8 32212254720 134217728 32212254720
Arbeitsspeicheroptimiert 16 65498251264 134217728 65498251264
Arbeitsspeicheroptimiert 32 132070244352 134217728 132070244352

Server für den Speichertyp „Universell v2“ (unterstützt bis zu 16 TB)

Preisstufe vCore(s) Standardwert (Bytes) Mindestwert (Bytes) Höchstwert (Bytes)
Basic 1 872415232 134217728 872415232
Basic 2 2684354560 134217728 2684354560
Universell 2 7516192768 134217728 7516192768
Universell 4 16106127360 134217728 16106127360
Universell 8 32212254720 134217728 32212254720
Universell 16 65498251264 134217728 65498251264
Universell 32 132070244352 134217728 132070244352
Universell 64 264140488704 134217728 264140488704
Arbeitsspeicheroptimiert 2 15032385536 134217728 15032385536
Arbeitsspeicheroptimiert 4 32212254720 134217728 32212254720
Arbeitsspeicheroptimiert 8 64424509440 134217728 64424509440
Arbeitsspeicheroptimiert 16 130996502528 134217728 130996502528
Arbeitsspeicheroptimiert 32 264140488704 134217728 264140488704

innodb_file_per_table

MySQL speichert die InnoDB-Tabelle basierend auf der Konfiguration, die Sie während der Tabellenerstellung angegeben haben, in verschiedenen Tabellenbereichen. 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.

Sie steuern dieses Verhalten mithilfe des innodb_file_per_table-Serverparameters. Durch Festlegen von innodb_file_per_table auf OFF werden Tabellen von InnoDB im Systemtabellenbereich erstellt. Andernfalls werden die Tabellen von InnoDB im „file-per-table“-Tabellenbereich erstellt.

Hinweis

innodb_file_per_table kann nur in den Tarifen „Universell“ und „Arbeitsspeicheroptimiert“ für die Speichertypen Universell v2 und Universell v1 aktualisiert werden.

Azure Database for MySQL unterstützt (maximal) bis zu 4 TB in einer einzelnen Datendatei im Speichertyp „Universell v2“. Wenn die Datenbankgröße 4 TB überschreitet, sollten Sie die Tabelle im Tabellenbereich innodb_file_per_table erstellen. Wenn eine einzelne Tabelle größer als 4 TB ist, müssen Sie die Partitionstabelle verwenden.

join_buffer_size

Weitere Informationen zu diesem Parameter finden Sie in der MySQL-Dokumentation.

Preisstufe vCore(s) Standardwert (Bytes) Mindestwert (Bytes) Höchstwert (Bytes)
Basic 1 Nicht konfigurierbar im Basic-Tarif – –
Basic 2 Nicht konfigurierbar im Basic-Tarif – –
Universell 2 262144 128 268435455
Universell 4 262144 128 536870912
Universell 8 262144 128 1073741824
Universell 16 262144 128 2147483648
Universell 32 262144 128 4294967295
Universell 64 262144 128 4294967295
Arbeitsspeicheroptimiert 2 262144 128 536870912
Arbeitsspeicheroptimiert 4 262144 128 1073741824
Arbeitsspeicheroptimiert 8 262144 128 2147483648
Arbeitsspeicheroptimiert 16 262144 128 4294967295
Arbeitsspeicheroptimiert 32 262144 128 4294967295

max_connections

Preisstufe vCore(s) Standardwert Mindestwert Höchstwert
Basic 1 50 10 50
Basic 2 100 10 100
Universell 2 300 10 600
Universell 4 625 10 1250
Universell 8 1250 10 2500
Universell 16 2500 10 5.000
Universell 32 5.000 10 10000
Universell 64 10000 10 20000
Arbeitsspeicheroptimiert 2 625 10 1250
Arbeitsspeicheroptimiert 4 1250 10 2500
Arbeitsspeicheroptimiert 8 2500 10 5.000
Arbeitsspeicheroptimiert 16 5.000 10 10000
Arbeitsspeicheroptimiert 32 10000 10 20000

Wenn die Anzahl der Verbindungen den Grenzwert überschreitet, erhalten Sie möglicherweise einen Fehler.

Tipp

Um Verbindungen effizient zu verwalten, bietet es sich an, einen Verbindungspooler wie ProxySQL zu verwenden. Weitere Informationen zum Einrichten von ProxySQL finden Sie im Blogbeitrag Load balance read replicas using ProxySQL in Azure Database for MySQL (Vornehmen eines Lastenausgleichs für Lesereplikate mit ProxySQL in Azure Database for MySQL). Beachten Sie, dass ProxySQL ein Open-Source-Communitytool ist. Es wird von Microsoft bestmöglich unterstützt.

max_heap_table_size

Weitere Informationen zu diesem Parameter finden Sie in der MySQL-Dokumentation.

Preisstufe vCore(s) Standardwert (Bytes) Mindestwert (Bytes) Höchstwert (Bytes)
Basic 1 Nicht konfigurierbar im Basic-Tarif – –
Basic 2 Nicht konfigurierbar im Basic-Tarif – –
Universell 2 16777216 16384 268435455
Universell 4 16777216 16384 536870912
Universell 8 16777216 16384 1073741824
Universell 16 16777216 16384 2147483648
Universell 32 16777216 16384 4294967295
Universell 64 16777216 16384 4294967295
Arbeitsspeicheroptimiert 2 16777216 16384 536870912
Arbeitsspeicheroptimiert 4 16777216 16384 1073741824
Arbeitsspeicheroptimiert 8 16777216 16384 2147483648
Arbeitsspeicheroptimiert 16 16777216 16384 4294967295
Arbeitsspeicheroptimiert 32 16777216 16384 4294967295

query_cache_size

Der Abfragecache ist standardmäßig deaktiviert. Um den Abfragecache zu aktivieren, konfigurieren Sie den Parameter query_cache_type.

Weitere Informationen zu diesem Parameter finden Sie in der MySQL-Dokumentation.

Hinweis

Der Abfragecache ist seit MySQL 5.7.20 veraltet und wurde in MySQL 8.0 entfernt.

Preisstufe vCore(s) Standardwert (Bytes) Mindestwert (Bytes) Höchstwert
Basic 1 Nicht konfigurierbar im Basic-Tarif – –
Basic 2 Nicht konfigurierbar im Basic-Tarif – –
Universell 2 0 0 16777216
Universell 4 0 0 33554432
Universell 8 0 0 67108864
Universell 16 0 0 134217728
Universell 32 0 0 134217728
Universell 64 0 0 134217728
Arbeitsspeicheroptimiert 2 0 0 33554432
Arbeitsspeicheroptimiert 4 0 0 67108864
Arbeitsspeicheroptimiert 8 0 0 134217728
Arbeitsspeicheroptimiert 16 0 0 134217728
Arbeitsspeicheroptimiert 32 0 0 134217728

lower_case_table_names

Der lower_case_table_name-Parameter ist standardmäßig auf 1 festgelegt, und Sie können diesen Parameter in MySQL 5.6 und MySQL 5.7 aktualisieren.

Weitere Informationen zu diesem Parameter finden Sie in der MySQL-Dokumentation.

Hinweis

In MySQL 8.0 ist lower_case_table_name standardmäßig auf 1 festgelegt, und Sie können diesen Wert nicht ändern.

innodb_strict_mode

Wenn Sie einen Fehler ähnlich Row size too large (> 8126)erhalten, sollten Sie den innodb_strict_mode-Parameter deaktivieren. Sie könneninnodb_strict_mode nicht global auf Serverebene ändern. Wenn die Zeilendatengröße größer als 8.000 ist, werden die Daten ohne Fehlerbenachrichtigung abgeschnitten, was zu potenziellen Datenverlusten führt. 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. Informationen zum Festlegen von innodb_strict_mode auf Sitzungsebene finden Sie unter Festlegen eines nicht aufgeführten Parameters.

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.

sort_buffer_size

Weitere Informationen zu diesem Parameter finden Sie in der MySQL-Dokumentation.

Preisstufe vCore(s) Standardwert (Bytes) Mindestwert (Bytes) Höchstwert (Bytes)
Basic 1 Nicht konfigurierbar im Basic-Tarif – –
Basic 2 Nicht konfigurierbar im Basic-Tarif – –
Universell 2 524288 32768 4194304
Universell 4 524288 32768 8388608
Universell 8 524288 32768 16777216
Universell 16 524288 32768 33554432
Universell 32 524288 32768 33554432
Universell 64 524288 32768 33554432
Arbeitsspeicheroptimiert 2 524288 32768 8388608
Arbeitsspeicheroptimiert 4 524288 32768 16777216
Arbeitsspeicheroptimiert 8 524288 32768 33554432
Arbeitsspeicheroptimiert 16 524288 32768 33554432
Arbeitsspeicheroptimiert 32 524288 32768 33554432

tmp_table_size

Weitere Informationen zu diesem Parameter finden Sie in der MySQL-Dokumentation.

Preisstufe vCore(s) Standardwert (Bytes) Mindestwert (Bytes) Höchstwert (Bytes)
Basic 1 Nicht konfigurierbar im Basic-Tarif – –
Basic 2 Nicht konfigurierbar im Basic-Tarif – –
Universell 2 16777216 1024 67108864
Universell 4 16777216 1024 134217728
Universell 8 16777216 1024 268435456
Universell 16 16777216 1024 536870912
Universell 32 16777216 1024 1073741824
Universell 64 16777216 1024 1073741824
Arbeitsspeicheroptimiert 2 16777216 1024 134217728
Arbeitsspeicheroptimiert 4 16777216 1024 268435456
Arbeitsspeicheroptimiert 8 16777216 1024 536870912
Arbeitsspeicheroptimiert 16 16777216 1024 1073741824
Arbeitsspeicheroptimiert 32 16777216 1024 1073741824

Warmup des InnoDB-Pufferpools

Nachdem Sie Azure Database for MySQL neu gestartet haben, werden die Datenseiten, die sich auf dem Datenträger befinden, geladen, wenn die Tabellen abgefragt werden. Dies führt zu erhöhten Wartezeiten und langsamerer Leistung bei der ersten Ausführung der Abfragen. Für Workloads, die latenzabhängig sind, kann diese langsamere Leistung nicht akzeptabel sein.

Sie können das Warmup des InnoDB-Pufferpools verwenden, um den Warmupzeitraum zu verkürzen. Dieser Prozess lädt Datenträgerseiten erneut, die sich vor dem Neustart im Pufferpool befanden, anstatt auf DML- oder SELECT-Vorgänge zu warten, um auf die entsprechenden Zeilen zuzugreifen. Weitere Informationen finden Sie unter Serverparameter des InnoDB-Pufferpools.

Die verbesserte Leistung geht jedoch auf Kosten einer längeren Startzeit des Servers. Wenn Sie diesen Parameter aktivieren, werden sich die Start- und Neustartzeiten des Servers, abhängig von den auf dem Server bereitgestellten IOPS, voraussichtlich verlängern. Es wird empfohlen, die Neustartzeit zu testen und zu überwachen, um sicherzustellen, dass die Leistung bei Starts bzw. Neustarts akzeptabel ist, weil der Server während dieser Zeit nicht verfügbar ist. Verwenden Sie diesen Parameter nicht, wenn weniger als 1000 IOPS bereitgestellt werden (mit anderen Worten, wenn der bereitgestellte Speicherplatz kleiner als 335 GB ist).

Wenn Sie den Zustand des Pufferpools beim Herunterfahren des Servers speichern möchten, legen Sie den Serverparameter innodb_buffer_pool_dump_at_shutdown auf ON fest. Legen Sie entsprechend den Serverparameter innodb_buffer_pool_load_at_startup auf ON fest, um den Pufferpoolzustand beim Serverstart wiederherzustellen. Sie können die Auswirkung auf die Start-bzw. Neustartdauer steuern, indem Sie den Wert des Serverparameters innodb_buffer_pool_dump_pct verringern und optimieren. Dieser Parameter ist standardmäßig auf 25 festgelegt.

Hinweis

Die Aufwärmparameter des InnoDB-Pufferpools werden nur auf universellen Speicherservern mit maximal 16 TB Speicher unterstützt. Weitere Informationen finden Sie unter Speicheroptionen von Azure Database for MySQL.

time_zone

Bei der ersten Bereitstellung enthält ein Server, der Azure Database for MySQL ausführt, Systemtabellen für Zeitzoneninformationen, aber diese Tabellen sind nicht mit Daten aufgefüllt. Sie können die Tabellen mit Daten auffüllen, indem Sie die gespeicherte mysql.az_load_timezone-Prozedur über Tools wie die MySQL-Befehlszeile oder MySQL Workbench aufrufen. Informationen zum Aufrufen der gespeicherten Prozeduren und zum Festlegen der globalen Zeitzonen oder Zeitzonen auf Sitzungsebene finden Sie unter Arbeiten mit dem Zeitzonenparameter (Azure-Portal) oder Arbeiten mit dem Zeitzonenparameter (Azure CLI).

binlog_expire_logs_seconds

In Azure Database for MySQL gibt dieser 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. Es enthält auch Ereignisse für Anweisungen, die möglicherweise Änderungen vornehmen können. 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 bereinigt werden. Wenn binäre Protokolle länger beibehalten werden sollen, können Sie den Parameter binlog_expire_logs_secondskonfigurieren. Wenn Sie binlog_expire_logs_seconds auf 0 festlegen (Standardwert), erfolgt die Bereinigung, sobald das Handle für das Binärprotokoll freigegeben wird. Wenn Sie binlog_expire_logs_seconds auf einen Wert größer als 0 festlegen, wird das Binärprotokoll erst nach diesem Zeitraum bereinigt.

Für Azure Database for MySQL werden verwaltete Features wie das Löschen von Binärdateien aus Sicherungen und Lesereplikaten intern behandelt. Wenn Sie die Daten aus dem Azure Database for MySQL-Dienst replizieren, müssen Sie diesen Parameter am primären Speicherort festlegen, 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ärprotokolle nicht schnell genug bereinigt. Dies kann zu einer Erhöhung der Abrechnung für Speicher führen.

event_scheduler

In Azure Database for MySQL verwaltet der Server-Parameter event_schedule das Erstellen, Planen und Ausführen von Ereignissen, d. h. von Aufgaben, die nach einem Zeitplan ausgeführt werden. Diese Aufgaben werden von einem speziellen Ereignisplaner-Thread ausgeführt. Wenn der event_scheduler-Parameter aktiviert ist, wird der Ereignisplaner-Thread in der Ausgabe von SHOW PROCESSLIST als Daemon-Prozess aufgeführt. 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>;

Hinweis

Weitere Informationen über die Erstellung eines Ereignisses finden Sie in der Dokumentation zu MySQL Event Scheduler:

Konfigurieren des event_scheduler-Serverparameters

Das folgende Szenario veranschaulicht eine Möglichkeit zur Verwendung des event_scheduler-Parameters in Azure Database for MySQL. 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)

Führen Sie zum Konfigurieren des Serverparameters event_scheduler in Azure Database for MySQL die folgenden Schritte aus:

  1. Navigieren Sie im Azure-Portal zu Ihrem Server und wählen Sie unter Einstellungen die Option Serverparameter aus.

  2. Suchen Sie auf dem Blatt Serverparameter nach event_scheduler. Wählen Sie in der Dropdownliste VALUE die Option EIN und dann Speichern aus.

    Hinweis

    Die Änderung der dynamischen Serverparameterkonfiguration wird ohne Neustart bereitgestellt.

  3. Stellen Sie dann eine Verbindung zum MySQL-Server her, um ein Ereignis zu erstellen, und führen Sie den folgenden SQL-Befehl aus:

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

  4. Um die Details des Event Schedulers anzuzeigen, führen Sie die folgende SQL-Anweisung aus:

    SHOW EVENTS;

    Die folgende Ausgabe wird angezeigt:

    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)

  5. Fragen Sie nach einigen Minuten die Zeilen aus der Tabelle ab, um die Zeilen anzuzeigen, die jede Minute gemäß dem von Ihnen konfigurierten Parameter event_scheduler eingefügt werden:

    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)

  6. Führen Sie nach einer Stunde eine Select-Anweisung für die Tabelle aus, um das vollständige Ergebnis der in die Tabelle eingefügten Werte jede Minute für eine Stunde anzuzeigen, wie event_scheduler in unserem Fall konfiguriert ist.

    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)

Andere Szenarien

Sie können ein Ereignis einrichten, das den Anforderungen Ihres spezifischen Szenarios entspricht. Es folgen einige ähnliche Beispiele für die Planung von SQL-Anweisungen, die in unterschiedlichen Zeitabständen ausgeführt werden sollen.

Führen Sie jetzt eine SQL-Anweisung aus, und lassen Sie sie einmal pro Tag unbegrenzt wiederholen

CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 DAY
STARTS (TIMESTAMP(CURRENT_DATE) + INTERVAL 1 DAY + INTERVAL 1 HOUR)
COMMENT 'Comment'
DO
<your statement>;

Unbegrenzte stündliche Ausführung einer SQL-Anweisung

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

Unbegrenzte tägliche Ausführung einer 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>;

Nicht konfigurierbare Serverparameter

Die folgenden Serverparameter können im Dienst nicht konfiguriert werden:

Parameter Fester Wert
innodb_file_per_table im Basic-Tarif OFF
innodb_flush_log_at_trx_commit 1
sync_binlog 1
innodb_log_file_size 256 MB
innodb_log_files_in_group 2

Andere Variablen, die hier nicht aufgeführt sind, werden auf die MySQL-Standardwerte festgelegt. Informationen zu den Versionen 8.0, 5.7 und 5.6 finden Sie in der MySQL-Dokumentation.

Nächste Schritte