Serverparameters in Azure Database for MySQL

  • Artikel

VAN TOEPASSING OP: Azure Database for MySQL - enkele server

Belangrijk

Azure Database for MySQL enkele server bevindt zich op het buitengebruikstellingspad. We raden u ten zeerste aan een upgrade uit te voeren naar een flexibele Azure Database for MySQL-server. Zie Wat gebeurt er met Azure Database for MySQL Enkele server voor meer informatie over migreren naar Azure Database for MySQL Flexibele server ?

Dit artikel bevat overwegingen en richtlijnen voor het configureren van serverparameters in Azure Database for MySQL.

Wat zijn serverparameters?

De MySQL-engine biedt veel verschillende servervariabelen en -parameters die u gebruikt om het gedrag van de engine te configureren en af te stemmen. Sommige parameters kunnen dynamisch worden ingesteld tijdens runtime, terwijl andere statisch zijn en vereisen dat de server opnieuw wordt opgestart om toe te passen.

Azure Database for MySQL biedt de mogelijkheid om de waarde van verschillende MySQL-serverparameters te wijzigen met behulp van Azure Portal, de Azure CLI en PowerShell , zodat deze overeenkomt met de behoeften van uw workload.

Configureerbare serverparameters

De lijst met ondersteunde serverparameters groeit voortdurend. Gebruik in Azure Portal het tabblad Serverparameters om de volledige lijst weer te geven en serverparameters te configureren.

Raadpleeg de volgende secties voor meer informatie over de limieten van verschillende veelgebruikte serverparameters. De limieten worden bepaald door de prijscategorie en vCores van de server.

Threadpools

MySQL wijst traditioneel een thread toe voor elke clientverbinding. Naarmate het aantal gelijktijdige gebruikers toeneemt, is er een overeenkomstige daling van de prestaties. Veel actieve threads kunnen de prestaties aanzienlijk beïnvloeden, vanwege een verhoogde contextwisseling, threadconflicten en slechte locatie voor CPU-caches.

Threadpools, een functie aan de serverzijde en verschillen van groepsgewijze verbindingen, maximaliseren de prestaties door een dynamische pool met werkrolthreads te introduceren. U gebruikt deze functie om het aantal actieve threads op de server te beperken en het verloop van threads te minimaliseren. Dit zorgt ervoor dat een burst van verbindingen ervoor zorgt dat de server geen resources of geheugen meer heeft. Threadpools zijn het meest efficiënt voor korte query's en CPU-intensieve workloads, zoals OLTP-workloads.

Zie Inleiding tot threadgroepen in Azure Database for MySQL voor meer informatie.

Notitie

Threadpools worden niet ondersteund voor MySQL 5.6.

De threadgroep configureren

Als u een threadgroep wilt inschakelen, werkt u de thread_handling serverparameter bij naar pool-of-threads. Deze parameter is standaard ingesteld op one-thread-per-connection, wat betekent dat MySQL voor elke nieuwe verbinding een nieuwe thread maakt. Dit is een statische parameter en vereist dat de server opnieuw wordt opgestart om toe te passen.

U kunt ook het maximum- en minimumaantal threads in de pool configureren door de volgende serverparameters in te stellen:

  • thread_pool_max_threads: Deze waarde beperkt het aantal threads in de pool.
  • thread_pool_min_threads: Met deze waarde wordt het aantal threads ingesteld dat is gereserveerd, zelfs nadat verbindingen zijn gesloten.

Als u prestatieproblemen van korte query's in de threadgroep wilt verbeteren, kunt u batchuitvoering inschakelen. In plaats van direct na het uitvoeren van een query terug te keren naar de threadgroep, blijven threads kort actief om te wachten op de volgende query via deze verbinding. De thread voert de query vervolgens snel uit en, wanneer dit is voltooid, wacht de thread op de volgende. Dit proces wordt voortgezet totdat de totale tijd die is besteed een drempelwaarde overschrijdt.

U bepaalt het gedrag van batchuitvoering met behulp van de volgende serverparameters:

  • thread_pool_batch_wait_timeout: Deze waarde geeft de tijd aan waarop een thread wacht tot een andere query wordt verwerkt.
  • thread_pool_batch_max_time: Deze waarde bepaalt de maximale tijd waarop een thread de cyclus van de uitvoering van de query herhaalt en wacht op de volgende query.

Belangrijk

Schakel de threadgroep pas in productie als u deze hebt getest.

log_bin_trust_function_creators

In Azure Database for MySQL zijn binaire logboeken altijd ingeschakeld (de log_bin parameter is ingesteld op ON). Als u triggers wilt gebruiken, krijgt u een foutmelding die vergelijkbaar is met het volgende: U beschikt niet over de SUPER-bevoegdheid en binaire logboekregistratie is ingeschakeld (u kunt de minder veilige log_bin_trust_function_creators variabele gebruiken).

De indeling voor binaire logboekregistratie is altijd ROW en alle verbindingen met de server maken altijd gebruik van binaire logboekregistratie op basis van rijen. Binaire logboekregistratie op basis van rijen helpt beveiliging te handhaven en binaire logboekregistratie kan niet worden onderbroken, zodat u veilig kunt instellen log_bin_trust_function_creators op TRUE.

innodb_buffer_pool_size

Raadpleeg de MySQL-documentatie voor meer informatie over deze parameter.

Servers op opslag voor algemeen gebruik v1 (ondersteuning voor maximaal 4 TB)

Prijscategorie vCore(s) Standaardwaarde (bytes) Minimale waarde (bytes) Maximumwaarde (bytes)
Basis 1 872415232 134217728 872415232
Basis 2 2684354560 134217728 2684354560
Algemeen gebruik 2 3758096384 134217728 3758096384
Algemeen gebruik 4 8053063680 134217728 8053063680
Algemeen gebruik 8 16106127360 134217728 16106127360
Algemeen gebruik 16 32749125632 134217728 32749125632
Algemeen gebruik 32 66035122176 134217728 66035122176
Algemeen gebruik 64 132070244352 134217728 132070244352
Geoptimaliseerd geheugen 2 7516192768 134217728 7516192768
Geoptimaliseerd geheugen 4 16106127360 134217728 16106127360
Geoptimaliseerd geheugen 8 32212254720 134217728 32212254720
Geoptimaliseerd geheugen 16 65498251264 134217728 65498251264
Geoptimaliseerd geheugen 32 132070244352 134217728 132070244352

Servers op opslag voor algemeen gebruik v2 (ondersteuning voor maximaal 16 TB)

Prijscategorie vCore(s) Standaardwaarde (bytes) Minimale waarde (bytes) Maximumwaarde (bytes)
Basis 1 872415232 134217728 872415232
Basis 2 2684354560 134217728 2684354560
Algemeen gebruik 2 7516192768 134217728 7516192768
Algemeen gebruik 4 16106127360 134217728 16106127360
Algemeen gebruik 8 32212254720 134217728 32212254720
Algemeen gebruik 16 65498251264 134217728 65498251264
Algemeen gebruik 32 132070244352 134217728 132070244352
Algemeen gebruik 64 264140488704 134217728 264140488704
Geoptimaliseerd geheugen 2 15032385536 134217728 15032385536
Geoptimaliseerd geheugen 4 32212254720 134217728 32212254720
Geoptimaliseerd geheugen 8 64424509440 134217728 64424509440
Geoptimaliseerd geheugen 16 130996502528 134217728 130996502528
Geoptimaliseerd geheugen 32 264140488704 134217728 264140488704

innodb_file_per_table

MySQL slaat de InnoDB tabel op in verschillende tabelruimten, op basis van de configuratie die u opgeeft tijdens het maken van de tabel. De systeemtabelruimte is het opslaggebied voor de InnoDB gegevenswoordenlijst. Een tabelruimte bestand per tabel bevat gegevens en indexen voor één InnoDB tabel en wordt opgeslagen in het bestandssysteem in een eigen gegevensbestand.

U bepaalt dit gedrag met behulp van de innodb_file_per_table serverparameter. Instelling innodb_file_per_table om ervoor te OFF zorgen dat InnoDB er tabellen worden gemaakt in de systeemtabelruimte. InnoDB Anders maakt u tabellen in tabelruimten per bestand.

Notitie

U kunt alleen bijwerken innodb_file_per_table in de prijscategorieën algemeen gebruik en geoptimaliseerd voor geheugen voor opslag voor algemeen gebruik v2 en opslag voor algemeen gebruik v1.

Azure Database for MySQL ondersteunt 4 TB (op het grootste) in één gegevensbestand op opslag voor algemeen gebruik v2. Als de database groter is dan 4 TB, moet u de tabel maken in de innodb_file_per_table tabelruimte. Als u één tabelgrootte hebt die groter is dan 4 TB, moet u de partitietabel gebruiken.

join_buffer_size

Raadpleeg de MySQL-documentatie voor meer informatie over deze parameter.

Prijscategorie vCore(s) Standaardwaarde (bytes) Minimale waarde (bytes) Maximumwaarde (bytes)
Basis 1 Kan niet worden geconfigureerd in de Basic-laag N.v.t. N.v.t.
Basis 2 Kan niet worden geconfigureerd in de Basic-laag N.v.t. N.v.t.
Algemeen gebruik 2 262144 128 268435455
Algemeen gebruik 4 262144 128 536870912
Algemeen gebruik 8 262144 128 1073741824
Algemeen gebruik 16 262144 128 2147483648
Algemeen gebruik 32 262144 128 4294967295
Algemeen gebruik 64 262144 128 4294967295
Geoptimaliseerd geheugen 2 262144 128 536870912
Geoptimaliseerd geheugen 4 262144 128 1073741824
Geoptimaliseerd geheugen 8 262144 128 2147483648
Geoptimaliseerd geheugen 16 262144 128 4294967295
Geoptimaliseerd geheugen 32 262144 128 4294967295

max_connections

Prijscategorie vCore(s) Standaardwaarde Minimumwaarde Maximumwaarde
Basis 1 50 10 50
Basis 2 100 10 100
Algemeen gebruik 2 300 10 600
Algemeen gebruik 4 625 10 1250
Algemeen gebruik 8 1250 10 2500
Algemeen gebruik 16 2500 10 5000
Algemeen gebruik 32 5000 10 10.000
Algemeen gebruik 64 10.000 10 20000
Geoptimaliseerd geheugen 2 625 10 1250
Geoptimaliseerd geheugen 4 1250 10 2500
Geoptimaliseerd geheugen 8 2500 10 5000
Geoptimaliseerd geheugen 16 5000 10 10.000
Geoptimaliseerd geheugen 32 10.000 10 20000

Wanneer het aantal verbindingen de limiet overschrijdt, wordt er mogelijk een fout weergegeven.

Tip

Als u verbindingen efficiënt wilt beheren, is het een goed idee om een verbindingspooler, zoals ProxySQL, te gebruiken. Zie het blogbericht Load balance leesreplica's met behulp van ProxySQL in Azure Database for MySQL voor meer informatie over het instellen van ProxySQL. ProxySQL is een opensource-communityhulpprogramma. Het wordt ondersteund door Microsoft op basis van best effort.

max_heap_table_size

Raadpleeg de MySQL-documentatie voor meer informatie over deze parameter.

Prijscategorie vCore(s) Standaardwaarde (bytes) Minimale waarde (bytes) Maximumwaarde (bytes)
Basis 1 Kan niet worden geconfigureerd in de Basic-laag N.v.t. N.v.t.
Basis 2 Kan niet worden geconfigureerd in de Basic-laag N.v.t. N.v.t.
Algemeen gebruik 2 16777216 16384 268435455
Algemeen gebruik 4 16777216 16384 536870912
Algemeen gebruik 8 16777216 16384 1073741824
Algemeen gebruik 16 16777216 16384 2147483648
Algemeen gebruik 32 16777216 16384 4294967295
Algemeen gebruik 64 16777216 16384 4294967295
Geoptimaliseerd geheugen 2 16777216 16384 536870912
Geoptimaliseerd geheugen 4 16777216 16384 1073741824
Geoptimaliseerd geheugen 8 16777216 16384 2147483648
Geoptimaliseerd geheugen 16 16777216 16384 4294967295
Geoptimaliseerd geheugen 32 16777216 16384 4294967295

query_cache_size

De querycache is standaard uitgeschakeld. Als u de querycache wilt inschakelen, configureert u de query_cache_type parameter.

Raadpleeg de MySQL-documentatie voor meer informatie over deze parameter.

Notitie

De querycache is afgeschaft vanaf MySQL 5.7.20 en is verwijderd in MySQL 8.0.

Prijscategorie vCore(s) Standaardwaarde (bytes) Minimale waarde (bytes) Maximumwaarde
Basis 1 Kan niet worden geconfigureerd in de Basic-laag N.v.t. N.v.t.
Basis 2 Kan niet worden geconfigureerd in de Basic-laag N.v.t. N.v.t.
Algemeen gebruik 2 0 0 16777216
Algemeen gebruik 4 0 0 33554432
Algemeen gebruik 8 0 0 6.7108.864
Algemeen gebruik 16 0 0 134217728
Algemeen gebruik 32 0 0 134217728
Algemeen gebruik 64 0 0 134217728
Geoptimaliseerd geheugen 2 0 0 33554432
Geoptimaliseerd geheugen 4 0 0 6.7108.864
Geoptimaliseerd geheugen 8 0 0 134217728
Geoptimaliseerd geheugen 16 0 0 134217728
Geoptimaliseerd geheugen 32 0 0 134217728

lower_case_table_names

De lower_case_table_name parameter is standaard ingesteld op 1 en u kunt deze parameter bijwerken in MySQL 5.6 en MySQL 5.7.

Raadpleeg de MySQL-documentatie voor meer informatie over deze parameter.

Notitie

In MySQL 8.0 lower_case_table_name is deze standaard ingesteld op 1 en kunt u deze niet wijzigen.

innodb_strict_mode

Als u een foutmelding krijgt die vergelijkbaar is met Row size too large (> 8126), kunt u overwegen de innodb_strict_mode parameter uit te schakelen. U kunt niet globaal wijzigen innodb_strict_mode op serverniveau. Als rijgegevens groter zijn dan 8.000, worden de gegevens afgekapt, zonder een foutmelding, wat leidt tot mogelijk gegevensverlies. Het is een goed idee om het schema aan te passen aan de limiet voor het paginaformaat.

U kunt deze parameter instellen op sessieniveau met behulp van init_connect. Als u wilt instellen innodb_strict_mode op sessieniveau, raadpleegt u de instellingsparameter die niet wordt vermeld.

Notitie

Als u een leesreplicaserver hebt, wordt de replicatie verbroken door de instelling innodb_strict_modeOFF op sessieniveau op sessieniveau op een bronserver. We raden u aan om de parameter ingesteld te ON houden als u replica's hebt gelezen.

sort_buffer_size

Raadpleeg de MySQL-documentatie voor meer informatie over deze parameter.

Prijscategorie vCore(s) Standaardwaarde (bytes) Minimale waarde (bytes) Maximumwaarde (bytes)
Basis 1 Kan niet worden geconfigureerd in de Basic-laag N.v.t. N.v.t.
Basis 2 Kan niet worden geconfigureerd in de Basic-laag N.v.t. N.v.t.
Algemeen gebruik 2 524288 32768 4194304
Algemeen gebruik 4 524288 32768 8388608
Algemeen gebruik 8 524288 32768 16777216
Algemeen gebruik 16 524288 32768 33554432
Algemeen gebruik 32 524288 32768 33554432
Algemeen gebruik 64 524288 32768 33554432
Geoptimaliseerd geheugen 2 524288 32768 8388608
Geoptimaliseerd geheugen 4 524288 32768 16777216
Geoptimaliseerd geheugen 8 524288 32768 33554432
Geoptimaliseerd geheugen 16 524288 32768 33554432
Geoptimaliseerd geheugen 32 524288 32768 33554432

tmp_table_size

Raadpleeg de MySQL-documentatie voor meer informatie over deze parameter.

Prijscategorie vCore(s) Standaardwaarde (bytes) Minimale waarde (bytes) Maximumwaarde (bytes)
Basis 1 Kan niet worden geconfigureerd in de Basic-laag N.v.t. N.v.t.
Basis 2 Kan niet worden geconfigureerd in de Basic-laag N.v.t. N.v.t.
Algemeen gebruik 2 16777216 1024 6.7108.864
Algemeen gebruik 4 16777216 1024 134217728
Algemeen gebruik 8 16777216 1024 268435456
Algemeen gebruik 16 16777216 1024 536870912
Algemeen gebruik 32 16777216 1024 1073741824
Algemeen gebruik 64 16777216 1024 1073741824
Geoptimaliseerd geheugen 2 16777216 1024 134217728
Geoptimaliseerd geheugen 4 16777216 1024 268435456
Geoptimaliseerd geheugen 8 16777216 1024 536870912
Geoptimaliseerd geheugen 16 16777216 1024 1073741824
Geoptimaliseerd geheugen 32 16777216 1024 1073741824

Opwarmen in innoDB-bufferpool

Nadat u Azure Database for MySQL opnieuw hebt opgestart, worden de gegevenspagina's die zich op de schijf bevinden, geladen terwijl er query's worden uitgevoerd op de tabellen. Dit leidt tot een hogere latentie en tragere prestaties voor de eerste uitvoering van de query's. Voor workloads die gevoelig zijn voor latentie, is deze tragere prestaties mogelijk onaanvaardbaar.

U kunt bufferpoolwarming gebruiken InnoDB om de opwarmperiode te verkorten. Met dit proces worden schijfpagina's die zich vóór het opnieuw opstarten in de buffergroep bevonden, opnieuw geladen in plaats van te wachten op DML- of SELECT-bewerkingen voor toegang tot de bijbehorende rijen. Zie InnoDB-buffergroepserverparameters voor meer informatie.

Verbeterde prestaties gaan echter ten koste van langere opstarttijd voor de server. Wanneer u deze parameter inschakelt, worden de opstart- en herstarttijden van de server naar verwachting verhoogd, afhankelijk van de IOPS die op de server is ingericht. Het is een goed idee om de opstarttijd te testen en te controleren, om ervoor te zorgen dat de opstart- of herstartprestaties acceptabel zijn, omdat de server gedurende die tijd niet beschikbaar is. Gebruik deze parameter niet wanneer het aantal ingerichte IOPS kleiner is dan 1000 IOPS (met andere woorden, wanneer de ingerichte opslag kleiner is dan 335 GB).

Als u de status van de buffergroep bij het afsluiten van de server wilt opslaan, stelt u de serverparameter in innodb_buffer_pool_dump_at_shutdown op ON. Stel op dezelfde manier de serverparameter innodb_buffer_pool_load_at_startup in om ON de status van de buffergroep te herstellen bij het opstarten van de server. U kunt de impact op het opstarten of opnieuw opstarten beheren door de waarde van de serverparameter innodb_buffer_pool_dump_pctte verlagen en af te stemmen. Deze parameter is standaard ingesteld op 25.

Notitie

InnoDB opwarmparameters voor buffergroepen worden alleen ondersteund in opslagservers voor algemeen gebruik met een opslag van maximaal 16 TB. Zie Azure Database for MySQL-opslagopties voor meer informatie.

time_zone

Bij de eerste implementatie bevat een server met Azure Database for MySQL systeemtabellen voor tijdzonegegevens, maar deze tabellen worden niet ingevuld. U kunt de tabellen vullen door de mysql.az_load_timezone opgeslagen procedure aan te roepen vanuit hulpprogramma's zoals de MySQL-opdrachtregel of MySQL Workbench. Zie Werken met de tijdzoneparameter (Azure Portal) of werken met de tijdzone (Azure CLI) voor informatie over het aanroepen van de opgeslagen procedures en het instellen van de tijdzonezones of het instellen van tijdzonezones.

binlog_expire_logs_seconds

In Azure Database for MySQL geeft deze parameter het aantal seconden aan dat de service wacht voordat het binaire logboekbestand wordt verwijderd.

Het binaire logboek bevat gebeurtenissen die databasewijzigingen beschrijven, zoals bewerkingen voor het maken van tabellen of wijzigingen in tabelgegevens. Het bevat ook gebeurtenissen voor instructies die mogelijk wijzigingen kunnen aanbrengen. Het binaire logboek wordt voornamelijk gebruikt voor twee doeleinden, replicatie- en gegevensherstelbewerkingen.

Normaal gesproken worden de binaire logboeken verwijderd zodra de ingang vrij is van de service, back-up of de replicaset. Als er meerdere replica's zijn, wachten de binaire logboeken tot de langzaamste replica de wijzigingen heeft gelezen voordat ze worden opgeschoond. Als u wilt dat binaire logboeken langer worden bewaard, kunt u de parameter binlog_expire_logs_secondsconfigureren. Als u instelt binlog_expire_logs_seconds op 0, wat de standaardwaarde is, wordt deze verwijderd zodra de ingang naar het binaire logboek wordt vrijgemaakt. Als u instelt binlog_expire_logs_seconds op groter dan 0, wordt het binaire logboek alleen na die periode verwijderd.

Voor Azure Database for MySQL worden beheerde functies zoals back-up en leesreplica's opschonen van binaire bestanden intern verwerkt. Wanneer u de gegevens uit de Azure Database for MySQL-service repliceert, moet u deze parameter instellen in de primaire database om te voorkomen dat binaire logboeken worden verwijderd voordat de replica wordt gelezen uit de wijzigingen van de primaire. Als u de binlog_expire_logs_seconds waarde instelt op een hogere waarde, worden de binaire logboeken niet snel genoeg opgeschoond. Dit kan leiden tot een toename van de opslagfacturering.

event_scheduler

In Azure Database for MySQL beheert de event_schedule serverparameter het maken, plannen en uitvoeren van gebeurtenissen, d.w. taken die volgens een schema worden uitgevoerd en ze worden uitgevoerd door een speciale thread voor gebeurtenisplanners. Wanneer de event_scheduler parameter is ingesteld op AAN, wordt de gebeurtenisplannerthread weergegeven als een daemonproces in de uitvoer van SHOW PROCESSLIST. U kunt gebeurtenissen maken en plannen met behulp van de volgende SQL-syntaxis:

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

Notitie

Zie de MySQL Event Scheduler-documentatie hier voor meer informatie over het maken van een gebeurtenis:

De event_scheduler-serverparameter configureren

In het volgende scenario ziet u een manier om de event_scheduler parameter in Azure Database for MySQL te gebruiken. Bekijk het volgende voorbeeld, een eenvoudige tabel om het scenario te demonstreren:

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)

Voer de volgende stappen uit om de event_scheduler serverparameter in Azure Database for MySQL te configureren:

  1. Navigeer in Azure Portal naar uw server en selecteer vervolgens onder Instellingen serverparameters.

  2. Zoek op de blade Serverparameters naar event_scheduler, in de vervolgkeuzelijst WAARDE , selecteer AAN en selecteer vervolgens Opslaan.

    Notitie

    De configuratie van de parameterconfiguratie van de dynamische server wordt geïmplementeerd zonder opnieuw op te starten.

  3. Maak vervolgens een gebeurtenis, maak verbinding met de MySQL-server en voer de volgende SQL-opdracht uit:

    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. Voer de volgende SQL-instructie uit om de details van event scheduler weer te geven:

    SHOW EVENTS;

    De volgende uitvoer wordt weergegeven:

    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. Voer na enkele minuten een query uit op de rijen uit de tabel om te beginnen met het weergeven van de rijen die elke minuut zijn ingevoegd op basis van de event_scheduler parameter die u hebt geconfigureerd:

    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. Voer na een uur een Select-instructie uit in de tabel om het volledige resultaat weer te geven van de waarden die elke minuut in de tabel zijn ingevoegd, omdat deze event_scheduler in ons geval is geconfigureerd.

    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 scenario's

U kunt een gebeurtenis instellen op basis van de vereisten van uw specifieke scenario. Een paar vergelijkbare voorbeelden van het plannen van SQL-instructies die met verschillende tijdsintervallen moeten worden uitgevoerd, volgen.

Voer nu een SQL-instructie uit en herhaal één keer per dag zonder einde

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

Elk uur een SQL-instructie uitvoeren zonder einde

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

Elke dag een SQL-instructie uitvoeren zonder einde

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

Niet-geconfigureerde serverparameters

De volgende serverparameters kunnen niet worden geconfigureerd in de service:

Parameter Vaste waarde
innodb_file_per_table in de basic-laag UIT
innodb_flush_log_at_trx_commit 1
sync_binlog 1
innodb_log_file_size 256 MB
innodb_log_files_in_group 2

Andere variabelen die hier niet worden vermeld, zijn ingesteld op de standaard MySQL-waarden. Raadpleeg de MySQL-documenten voor versies 8.0, 5.7 en 5.6.

Volgende stappen