Parametri del server in Database di Azure per MySQL

  • Articolo

SI APPLICA A: Database di Azure per MySQL - Server singolo

Importante

Database di Azure per MySQL server singolo si trova nel percorso di ritiro. È consigliabile eseguire l'aggiornamento a Database di Azure per MySQL server flessibile. Per altre informazioni sulla migrazione a Database di Azure per MySQL server flessibile, vedere Che cosa accade a Database di Azure per MySQL server singolo?

Questo articolo fornisce considerazioni e linee guida per la configurazione dei parametri del server in Database di Azure per MySQL.

Che cosa sono i parametri del server?

Il motore MySQL fornisce molte variabili e parametri server diversi usati per configurare e ottimizzare il comportamento del motore. Alcuni parametri possono essere impostati in modo dinamico durante il runtime, mentre altri sono statici e richiedono un riavvio del server per applicarli.

Database di Azure per MySQL espone la possibilità di modificare il valore di vari parametri del server MySQL usando il portale di Azure, l'interfaccia della riga di comando di Azure e PowerShell per soddisfare le esigenze del carico di lavoro.

Parametri del server configurabili

L'elenco di parametri del server supportati è in continua crescita. Nella portale di Azure usare la scheda parametri del server per visualizzare l'elenco completo e configurare i valori dei parametri del server.

Per altre informazioni sui limiti di diversi parametri del server comunemente aggiornati, vedere le sezioni seguenti. I limiti sono determinati dal piano tariffario e dai vCore del server.

Pool di thread

MySQL assegna tradizionalmente un thread per ogni connessione client. Man mano che il numero di utenti simultanei aumenta, si verifica un calo delle prestazioni corrispondente. Molti thread attivi possono influire significativamente sulle prestazioni, a causa di un aumento del cambio di contesto, conflitti di thread e località non valida per le cache della CPU.

Pool di thread, una funzionalità lato server e distinta dal pool di connessioni, ottimizzano le prestazioni introducendo un pool dinamico di thread di lavoro. Questa funzionalità viene usata per limitare il numero di thread attivi in esecuzione nel server e ridurre al minimo la varianza del thread. In questo modo si garantisce che un burst di connessioni non causi l'esaurirsi delle risorse o della memoria del server. I pool di thread sono più efficienti per query brevi e carichi di lavoro a elevato utilizzo di CPU, ad esempio carichi di lavoro OLTP.

Per altre informazioni, vedere Introduzione ai pool di thread in Database di Azure per MySQL.

Nota

I pool di thread non sono supportati per MySQL 5.6.

Configurare il pool di thread

Per abilitare un pool di thread, aggiornare il parametro del thread_handling server a pool-of-threads. Per impostazione predefinita, questo parametro è impostato su one-thread-per-connection, il che significa che MySQL crea un nuovo thread per ogni nuova connessione. Si tratta di un parametro statico e richiede un riavvio del server da applicare.

È anche possibile configurare il numero massimo e minimo di thread nel pool impostando i parametri del server seguenti:

  • thread_pool_max_threads: questo valore limita il numero di thread nel pool.
  • thread_pool_min_threads: questo valore imposta il numero di thread riservati, anche dopo la chiusura delle connessioni.

Per migliorare i problemi di prestazioni delle query brevi nel pool di thread, è possibile abilitare l'esecuzione batch. Anziché tornare al pool di thread immediatamente dopo l'esecuzione di una query, i thread rimarranno attivi per un breve periodo di attesa per la query successiva tramite questa connessione. Il thread esegue quindi rapidamente la query e, al termine, il thread attende il successivo. Questo processo continua fino a quando il tempo complessivo impiegato supera una soglia.

Per determinare il comportamento dell'esecuzione batch, usare i parametri del server seguenti:

  • thread_pool_batch_wait_timeout: questo valore specifica il tempo in cui un thread attende l'elaborazione di un'altra query.
  • thread_pool_batch_max_time: questo valore determina il tempo massimo per cui un thread ripeterà il ciclo di esecuzione della query e attenderà la query successiva.

Importante

Non attivare il pool di thread nell'ambiente di produzione fino a quando non è stato testato.

log_bin_trust_function_creators

In Database di Azure per MySQL i log binari sono sempre abilitati (il log_bin parametro è impostato su ON). Se si desidera usare i trigger, viene visualizzato un errore simile al seguente: non si dispone del privilegio SUPER e la registrazione binaria è abilitata (è possibile usare la variabile meno sicura log_bin_trust_function_creators ) .

Il formato di registrazione binaria è sempre ROW e tutte le connessioni al server usano sempre la registrazione binaria basata su righe. La registrazione binaria basata su righe consente di mantenere la sicurezza e la registrazione binaria non può interrompersi, quindi è possibile impostare log_bin_trust_function_creators in modo sicuro su TRUE.

innodb_buffer_pool_size

Per altre informazioni su questo parametro, esaminare la documentazione di MySQL.

Server in archiviazione per utilizzo generico v1 (supporto fino a 4 TB)

Piano tariffario vCore Valore predefinito (byte) Valore minimo (byte) Valore massimo (byte)
Di base 1 872415232 134217728 872415232
Di base 2 2684354560 134217728 2684354560
Utilizzo generico 2 3758096384 134217728 3758096384
Utilizzo generico 4 8053063680 134217728 8053063680
Utilizzo generico 8 16106127360 134217728 16106127360
Utilizzo generico 16 32749125632 134217728 32749125632
Utilizzo generico 32 66035122176 134217728 66035122176
Utilizzo generico 64 132070244352 134217728 132070244352
Con ottimizzazione per la memoria 2 7516192768 134217728 7516192768
Con ottimizzazione per la memoria 4 16106127360 134217728 16106127360
Con ottimizzazione per la memoria 8 32212254720 134217728 32212254720
Con ottimizzazione per la memoria 16 65498251264 134217728 65498251264
Con ottimizzazione per la memoria 32 132070244352 134217728 132070244352

Server in archiviazione per utilizzo generico v2 (supporto fino a 16 TB)

Piano tariffario vCore Valore predefinito (byte) Valore minimo (byte) Valore massimo (byte)
Di base 1 872415232 134217728 872415232
Di base 2 2684354560 134217728 2684354560
Utilizzo generico 2 7516192768 134217728 7516192768
Utilizzo generico 4 16106127360 134217728 16106127360
Utilizzo generico 8 32212254720 134217728 32212254720
Utilizzo generico 16 65498251264 134217728 65498251264
Utilizzo generico 32 132070244352 134217728 132070244352
Utilizzo generico 64 264140488704 134217728 264140488704
Con ottimizzazione per la memoria 2 15032385536 134217728 15032385536
Con ottimizzazione per la memoria 4 32212254720 134217728 32212254720
Con ottimizzazione per la memoria 8 64424509440 134217728 64424509440
Con ottimizzazione per la memoria 16 130996502528 134217728 130996502528
Con ottimizzazione per la memoria 32 264140488704 134217728 264140488704

innodb_file_per_table

MySQL archivia la InnoDB tabella in spazi di tabella diversi, in base alla configurazione specificata durante la creazione della tabella. Lo spazio tabelle di sistema è l'area di archiviazione per il InnoDB dizionario dati. Uno spazio di tabella file per tabella contiene dati e indici per una singola InnoDB tabella e viene archiviato nel file system nel proprio file di dati.

È possibile controllare questo comportamento usando il parametro del innodb_file_per_table server. L'impostazione innodb_file_per_table di per OFF fare in modo che crei InnoDB tabelle nello spazio tabelle di sistema. In caso contrario, InnoDB crea tabelle in spazi di tabella per file per tabella.

Nota

È possibile eseguire l'aggiornamento innodb_file_per_table solo nei piani tariffari per utilizzo generico e ottimizzato per la memoria nell'archiviazione per utilizzo generico v2 e nell'archiviazione per utilizzo generico v1.

Database di Azure per MySQL supporta 4 TB (al massimo) in un singolo file di dati nell'archiviazione per utilizzo generico v2. Se le dimensioni del database sono superiori a 4 TB, è necessario creare la tabella nello spazio di tabella innodb_file_per_table . Se si dispone di una singola dimensione di tabella maggiore di 4 TB, è consigliabile usare la tabella di partizione.

join_buffer_size

Per altre informazioni su questo parametro, esaminare la documentazione di MySQL.

Piano tariffario vCore Valore predefinito (byte) Valore minimo (byte) Valore massimo (byte)
Di base 1 Non configurabile nel livello Basic N/D N/D
Di base 2 Non configurabile nel livello Basic N/D N/D
Utilizzo generico 2 262144 128 268435455
Utilizzo generico 4 262144 128 536870912
Utilizzo generico 8 262144 128 1073741824
Utilizzo generico 16 262144 128 2147483648
Utilizzo generico 32 262144 128 4294967295
Utilizzo generico 64 262144 128 4294967295
Con ottimizzazione per la memoria 2 262144 128 536870912
Con ottimizzazione per la memoria 4 262144 128 1073741824
Con ottimizzazione per la memoria 8 262144 128 2147483648
Con ottimizzazione per la memoria 16 262144 128 4294967295
Con ottimizzazione per la memoria 32 262144 128 4294967295

max_connections

Piano tariffario vCore Valore predefinito: Valore minimo Valore massimo
Di base 1 50 10 50
Di base 2 100 10 100
Utilizzo generico 2 300 10 600
Utilizzo generico 4 625 10 1250
Utilizzo generico 8 1250 10 2500
Utilizzo generico 16 2500 10 5000
Utilizzo generico 32 5000 10 10000
Utilizzo generico 64 10000 10 20000
Con ottimizzazione per la memoria 2 625 10 1250
Con ottimizzazione per la memoria 4 1250 10 2500
Con ottimizzazione per la memoria 8 2500 10 5000
Con ottimizzazione per la memoria 16 5000 10 10000
Con ottimizzazione per la memoria 32 10000 10 20000

Quando il numero di connessioni supera il limite, potrebbe essere visualizzato un errore.

Suggerimento

Per gestire le connessioni in modo efficiente, è consigliabile usare un pooler di connessioni, ad esempio ProxySQL. Per informazioni sulla configurazione di ProxySQL, vedere il post di blog Bilanciare il carico delle repliche in lettura usando ProxySQL in Database di Azure per MySQL. Si noti che ProxySQL è uno strumento della community open source. È supportato da Microsoft su base ottimale.

max_heap_table_size

Per altre informazioni su questo parametro, esaminare la documentazione di MySQL.

Piano tariffario vCore Valore predefinito (byte) Valore minimo (byte) Valore massimo (byte)
Di base 1 Non configurabile nel livello Basic N/D N/D
Di base 2 Non configurabile nel livello Basic N/D N/D
Utilizzo generico 2 16777216 16384 268435455
Utilizzo generico 4 16777216 16384 536870912
Utilizzo generico 8 16777216 16384 1073741824
Utilizzo generico 16 16777216 16384 2147483648
Utilizzo generico 32 16777216 16384 4294967295
Utilizzo generico 64 16777216 16384 4294967295
Con ottimizzazione per la memoria 2 16777216 16384 536870912
Con ottimizzazione per la memoria 4 16777216 16384 1073741824
Con ottimizzazione per la memoria 8 16777216 16384 2147483648
Con ottimizzazione per la memoria 16 16777216 16384 4294967295
Con ottimizzazione per la memoria 32 16777216 16384 4294967295

query_cache_size

La cache della query è disattivata per impostazione predefinita. Per abilitare la cache delle query, configurare il parametro query_cache_type.

Per altre informazioni su questo parametro, esaminare la documentazione di MySQL.

Nota

La cache delle query è deprecata a partire da MySQL 5.7.20 ed è stata rimossa in MySQL 8.0.

Piano tariffario vCore Valore predefinito (byte) Valore minimo (byte) Valore massimo
Di base 1 Non configurabile nel livello Basic N/D N/D
Di base 2 Non configurabile nel livello Basic N/D N/D
Utilizzo generico 2 0 0 16777216
Utilizzo generico 4 0 0 33554432
Utilizzo generico 8 0 0 67108864
Utilizzo generico 16 0 0 134217728
Utilizzo generico 32 0 0 134217728
Utilizzo generico 64 0 0 134217728
Con ottimizzazione per la memoria 2 0 0 33554432
Con ottimizzazione per la memoria 4 0 0 67108864
Con ottimizzazione per la memoria 8 0 0 134217728
Con ottimizzazione per la memoria 16 0 0 134217728
Con ottimizzazione per la memoria 32 0 0 134217728

lower_case_table_names

Il lower_case_table_name parametro è impostato su 1 per impostazione predefinita ed è possibile aggiornare questo parametro in MySQL 5.6 e MySQL 5.7.

Per altre informazioni su questo parametro, esaminare la documentazione di MySQL.

Nota

In MySQL 8.0 lower_case_table_name è impostato su 1 per impostazione predefinita e non è possibile modificarlo.

innodb_strict_mode

Se viene visualizzato un errore simile a Row size too large (> 8126), è consigliabile disattivare il innodb_strict_mode parametro . Non è possibile modificare innodb_strict_mode a livello globale a livello di server. Se le dimensioni dei dati delle righe sono maggiori di 8.000, i dati vengono troncati, senza una notifica di errore, causando una potenziale perdita di dati. È consigliabile modificare lo schema in base al limite di dimensioni della pagina.

È possibile impostare questo parametro a livello di sessione usando init_connect. Per impostare innodb_strict_mode a livello di sessione, fare riferimento all'impostazione del parametro non elencato.

Nota

Se si dispone di un server di replica in lettura, l'impostazione su innodb_strict_modeOFF a livello di sessione in un server di origine interromperà la replica. È consigliabile mantenere il parametro impostato su ON se sono presenti repliche in lettura.

sort_buffer_size

Per altre informazioni su questo parametro, esaminare la documentazione di MySQL.

Piano tariffario vCore Valore predefinito (byte) Valore minimo (byte) Valore massimo (byte)
Di base 1 Non configurabile nel livello Basic N/D N/D
Di base 2 Non configurabile nel livello Basic N/D N/D
Utilizzo generico 2 524288 32768 4194304
Utilizzo generico 4 524288 32768 8388608
Utilizzo generico 8 524288 32768 16777216
Utilizzo generico 16 524288 32768 33554432
Utilizzo generico 32 524288 32768 33554432
Utilizzo generico 64 524288 32768 33554432
Con ottimizzazione per la memoria 2 524288 32768 8388608
Con ottimizzazione per la memoria 4 524288 32768 16777216
Con ottimizzazione per la memoria 8 524288 32768 33554432
Con ottimizzazione per la memoria 16 524288 32768 33554432
Con ottimizzazione per la memoria 32 524288 32768 33554432

tmp_table_size

Per altre informazioni su questo parametro, esaminare la documentazione di MySQL.

Piano tariffario vCore Valore predefinito (byte) Valore minimo (byte) Valore massimo (byte)
Di base 1 Non configurabile nel livello Basic N/D N/D
Di base 2 Non configurabile nel livello Basic N/D N/D
Utilizzo generico 2 16777216 1024 67108864
Utilizzo generico 4 16777216 1024 134217728
Utilizzo generico 8 16777216 1024 268435456
Utilizzo generico 16 16777216 1024 536870912
Utilizzo generico 32 16777216 1024 1073741824
Utilizzo generico 64 16777216 1024 1073741824
Con ottimizzazione per la memoria 2 16777216 1024 134217728
Con ottimizzazione per la memoria 4 16777216 1024 268435456
Con ottimizzazione per la memoria 8 16777216 1024 536870912
Con ottimizzazione per la memoria 16 16777216 1024 1073741824
Con ottimizzazione per la memoria 32 16777216 1024 1073741824

Riscaldamento del pool di buffer innoDB

Dopo il riavvio Database di Azure per MySQL, vengono caricate le pagine di dati che risiedono nel disco, perché vengono eseguite query sulle tabelle. Ciò comporta un aumento della latenza e delle prestazioni più lente per la prima esecuzione delle query. Per i carichi di lavoro sensibili alla latenza, è possibile che le prestazioni più lente siano inaccettabili.

È possibile usare il InnoDB riscaldamento del pool di buffer per abbreviare il periodo di riscaldamento. Questo processo ricarica le pagine del disco presenti nel pool di buffer prima del riavvio, anziché attendere che le operazioni DML o edizione Standard LECT accevano alle righe corrispondenti. Per altre informazioni, vedere Parametri del server del pool di buffer InnoDB.

Tuttavia, le prestazioni sono migliorate a scapito del tempo di avvio più lungo per il server. Quando si abilita questo parametro, si prevede che i tempi di avvio e riavvio del server aumentino, a seconda delle operazioni di I/O al secondo di cui è stato effettuato il provisioning nel server. È consigliabile testare e monitorare l'ora di riavvio per assicurarsi che le prestazioni di avvio o riavvio siano accettabili, perché il server non è disponibile durante tale periodo. Non usare questo parametro quando il numero di operazioni di I/O al secondo di cui è stato effettuato il provisioning è minore di 1000 operazioni di I/O al secondo (in altre parole, quando lo spazio di archiviazione di cui è stato effettuato il provisioning è minore di 335 GB).

Per salvare lo stato del pool di buffer all'arresto del server, impostare il parametro innodb_buffer_pool_dump_at_shutdown del server su ON. Analogamente, impostare il parametro innodb_buffer_pool_load_at_startup del server su ON per ripristinare lo stato del pool di buffer all'avvio del server. È possibile controllare l'impatto sull'avvio o sul riavvio riducendo e ottimizzando il valore del parametro innodb_buffer_pool_dump_pctdel server . Per impostazione predefinita, il parametro è impostato su 25.

Nota

InnoDB I parametri di riscaldamento del pool di buffer sono supportati solo nei server di archiviazione per utilizzo generico con un massimo di 16 TB di archiviazione. Per altre informazioni, vedere Database di Azure per MySQL opzioni di archiviazione.

time_zone

Al momento della distribuzione iniziale, un server che esegue Database di Azure per MySQL include tabelle di sistemi per informazioni sul fuso orario, ma queste tabelle non vengono popolate. È possibile popolare le tabelle chiamando la mysql.az_load_timezone stored procedure da strumenti come la riga di comando di MySQL o MySQL Workbench. Per informazioni su come chiamare le stored procedure e impostare i fusi orari globali o a livello di sessione, vedere Uso del parametro del fuso orario (portale di Azure) o Uso del parametro del fuso orario (interfaccia della riga di comando di Azure).

binlog_expire_logs_seconds

In Database di Azure per MySQL questo parametro specifica il numero di secondi di attesa del servizio prima di eliminare il file di log binario.

Il log binario contiene eventi che descrivono le modifiche del database, ad esempio le operazioni di creazione di tabelle o le modifiche apportate ai dati della tabella. Contiene anche eventi per le istruzioni che possono potenzialmente apportare modifiche. Il log binario viene usato principalmente per due scopi, le operazioni di replica e ripristino dei dati.

In genere, i log binari vengono eliminati non appena l'handle è libero dal servizio, dal backup o dal set di repliche. Se sono presenti più repliche, i log binari attendono che la replica più lenta legga le modifiche prima di essere rimosse. Se si vuole che i log binari persistono più a lungo, è possibile configurare il parametro binlog_expire_logs_seconds. Se si imposta su binlog_expire_logs_seconds0, ovvero il valore predefinito, l'handle viene eliminato non appena viene liberato l'handle per il log binario. Se si imposta su binlog_expire_logs_seconds maggiore di 0, il log binario viene eliminato solo dopo tale periodo di tempo.

Per Database di Azure per MySQL, le funzionalità gestite come il backup e l'eliminazione delle repliche in lettura dei file binari vengono gestite internamente. Quando si replicano i dati dal servizio Database di Azure per MySQL, è necessario impostare questo parametro nel database primario per evitare di eliminare i log binari prima che la replica legga dalle modifiche dal database primario. Se si imposta su binlog_expire_logs_seconds un valore superiore, i log binari non verranno eliminati abbastanza presto. Ciò può comportare un aumento della fatturazione dell'archiviazione.

event_scheduler

In Database di Azure per MySQL il event_schedule parametro server gestisce la creazione, la pianificazione e l'esecuzione di eventi, ad esempio le attività eseguite in base a una pianificazione e vengono eseguite da un thread speciale dell'utilità di pianificazione eventi. Quando il event_scheduler parametro è impostato su ON, il thread dell'utilità di pianificazione eventi viene elencato come processo daemon nell'output di SHOW PROCESSLIST. È possibile creare e pianificare eventi usando la sintassi SQL seguente:

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

Nota

Per altre informazioni sulla creazione di un evento, vedere la documentazione dell'Utilità di pianificazione eventi MySQL qui:

Configurazione del parametro del server event_scheduler

Lo scenario seguente illustra un modo per usare il event_scheduler parametro in Database di Azure per MySQL. Per illustrare lo scenario, si consideri l'esempio seguente, una tabella semplice:

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)

Per configurare il parametro del event_scheduler server in Database di Azure per MySQL, seguire questa procedura:

  1. Nella portale di Azure passare al server e quindi in Impostazioni selezionare Parametri server.

  2. Nel pannello Parametri del server cercare event_scheduler, nell'elenco a discesa VALORE selezionare ON e quindi selezionare Salva.

    Nota

    La modifica della configurazione dei parametri del server dinamico verrà distribuita senza riavviare.

  3. Quindi, per creare un evento, connettersi al server MySQL ed eseguire il comando SQL seguente:

    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. Per visualizzare i dettagli dell'utilità di pianificazione eventi, eseguire l'istruzione SQL seguente:

    SHOW EVENTS;

    Viene visualizzato l'output seguente:

    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. Dopo alcuni minuti, eseguire una query sulle righe dalla tabella per iniziare a visualizzare le righe inserite ogni minuto in base al event_scheduler parametro configurato:

    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. Dopo un'ora, eseguire un'istruzione Select nella tabella per visualizzare il risultato completo dei valori inseriti nella tabella ogni minuto per un'ora, perché in questo caso viene configurato .event_scheduler

    mysql> select * from tab1;
+----+---------------------+-------------+
| id | CreatedAt           | CreatedBy   |
+----+---------------------+-------------+
|  1 | 2023-04-05 14:47:04 | azureuser@% |
|  2 | 2023-04-05 14:48:04 | azureuser@% |
|  3 | 2023-04-05 14:49:04 | azureuser@% |
|  4 | 2023-04-05 14:50:04 | azureuser@% |
|  5 | 2023-04-05 14:51:04 | azureuser@% |
|  6 | 2023-04-05 14:52:04 | azureuser@% |
..< 50 lines trimmed to compact output >..
| 56 | 2023-04-05 15:42:04 | azureuser@% |
| 57 | 2023-04-05 15:43:04 | azureuser@% |
| 58 | 2023-04-05 15:44:04 | azureuser@% |
| 59 | 2023-04-05 15:45:04 | azureuser@% |
| 60 | 2023-04-05 15:46:04 | azureuser@% |
| 61 | 2023-04-05 15:47:04 | azureuser@% |
+----+---------------------+-------------+
61 rows in set (0.23 sec)

Altri scenari

È possibile configurare un evento in base ai requisiti dello scenario specifico. Di seguito sono riportati alcuni esempi simili di pianificazione delle istruzioni SQL da eseguire a intervalli di tempo diversi.

Eseguire un'istruzione SQL ora e ripetere una volta al giorno senza fine

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

Eseguire un'istruzione SQL ogni ora senza fine

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

Eseguire un'istruzione SQL ogni giorno senza fine

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

Elenco di parametri del server non configurabili

I parametri del server seguenti non sono configurabili nel servizio:

Parametro Valore fisso
innodb_file_per_table nel livello basic OFF
innodb_flush_log_at_trx_commit 1
sync_binlog 1
innodb_log_file_size 256 MB
innodb_log_files_in_group 2

Altre variabili non elencate di seguito sono impostate sui valori mySQL predefiniti. Vedere la documentazione di MySQL per le versioni 8.0, 5.7 e 5.6.

Passaggi successivi