Parametri del server in Database di Azure per MySQL - Server flessibile

Articolo
01/04/2025

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

Nota

Questo articolo contiene riferimenti al termine slave, che Microsoft non usa più. Quando il termine verrà rimosso dal software, verrà rimosso anche dall'articolo.

Che cosa sono i parametri del server?

Il motore MySQL fornisce molti parametri del server (detti anche variabili) che è possibile usare per configurare e ottimizzare il comportamento del motore. Alcuni parametri possono essere impostati in modo dinamico durante il runtime. Altri sono statici e richiedono un riavvio del server dopo averli impostati.

In Database di Azure per MySQL - Server flessibile è possibile modificare il valore di vari parametri del server MySQL usando i parametri del server Configure in Database di Azure per MySQL - Flexible Server usando il portale di Azure e i parametri del server Configure in Database di Azure per MySQL: server flessibile che usa l'interfaccia della riga di comando di Azure per soddisfare le esigenze del carico di lavoro.

Elenco di parametri del server configurabili

È possibile gestire la configurazione di un server flessibile Database di Azure per MySQL usando i parametri del server. I parametri del server vengono configurati con i valori predefiniti e consigliati quando si crea il server. Il riquadro Parametri server nel portale di Azure mostra sia i parametri modificabili che non modificabili. I parametri del server non modificabili non sono disponibili.

L'elenco di parametri del server supportati è in continua crescita. È possibile usare il portale di Azure per visualizzare periodicamente l'elenco completo dei parametri del server e configurare i valori.

Se si modifica un parametro del server statico usando il portale, è necessario riavviare il server per rendere effettive le modifiche. Se si usano script di automazione (tramite strumenti come i modelli di Azure Resource Manager, Terraform o l'interfaccia della riga di comando di Azure), lo script deve avere un provisioning per riavviare il servizio per rendere effettive le impostazioni, anche se si modifica la configurazione come parte dell'esperienza di creazione.

Se si vuole modificare un parametro server non modificabile per l'ambiente, pubblicare un'idea tramite commenti e suggerimenti della community o votare se il feedback esiste già (che può essere utile per definire la priorità).

Le sezioni seguenti descrivono i limiti dei parametri del server comunemente aggiornati. Il livello di calcolo e le dimensioni (vCore) del server determinano i limiti.

lower_case_table_names

Per MySQL versione 5.7, il valore predefinito di lower_case_table_names è 1 in Database di Azure per MySQL - Server flessibile. Anche se è possibile modificare il valore supportato in 2, il ripristino da 2 a 1 non è consentito. Per assistenza nella modifica del valore predefinito, creare un ticket di supporto.

Per MySQL versione 8.0+ è possibile configurare lower_case_table_names solo quando si inizializza il server. Altre informazioni. La modifica dell'impostazione dopo l'inizializzazione lower_case_table_names del server non è consentita.

I valori supportati per MySQL versione 8.0 sono 1 e 2 in Database di Azure per MySQL - Server flessibile. Il valore predefinito è 1. Per assistenza nella modifica del valore predefinito durante la creazione del server, creare un ticket di supporto.

innodb_tmpdir

Usare il parametro innodb_tmpdir in Database di Azure per MySQL - Server flessibile per definire la directory per i file di ordinamento temporanei creati durante le operazioni online ALTER TABLE che vengono ricompilato.

Il valore predefinito di innodb_tmpdir è /mnt/temp. Questa posizione corrisponde all'archiviazione temporanea (SSD) ed è disponibile in gibibytes (GiB) con ogni dimensione di calcolo del server. Questa posizione è ideale per le operazioni che non richiedono una grande quantità di spazio.

Se è necessario più spazio, è possibile impostare su innodb_tmpdir /app/work/tmpdir. Questa impostazione usa la capacità di archiviazione disponibile nel server flessibile Database di Azure per MySQL. Questa impostazione può essere utile per operazioni di dimensioni maggiori che richiedono più spazio di archiviazione temporaneo.

Tenere presente che l'uso /app/work/tmpdir di restituisce prestazioni più lente rispetto al valore predefinito dell'archiviazione temporanea (SSD). /mnt/temp Scegliere in base ai requisiti specifici delle operazioni.

Le informazioni fornite per innodb_tmpdir sono applicabili ai parametri innodb_temp_tablespaces_dir, tmpdir e slave_load_tmpdir dove:

Il valore /mnt/temp predefinito è comune.
La directory /app/work/tmpdir alternativa è disponibile per la configurazione di un'archiviazione temporanea aumentata, con un compromesso nelle prestazioni in base a requisiti operativi specifici.

log_bin_trust_function_creators

In Database di Azure per MySQL - Server flessibile, i log binari sono sempre abilitati , ovvero log_bin è impostato su ON. Il log_bin_trust_function_creators parametro è impostato su ON per impostazione predefinita nei server flessibili.

Il formato di registrazione binaria è sempre ROWe le connessioni al server usano sempre la registrazione binaria basata su righe. Con la registrazione binaria basata su righe, i problemi di sicurezza non esistono e la registrazione binaria non può interrompersi, quindi è possibile consentire in modo sicuro di log_bin_trust_function_creators rimanere come ON.

Se log_bin_trust_function_creators è impostato su OFF e si tenta di creare trigger, è possibile che si verifichino errori simili a: "Non si dispone del privilegio SUPER e la registrazione binaria è abilitata (è possibile usare la variabile meno sicura log_bin_trust_function_creators )."

innodb_buffer_pool_size

Per informazioni sul innodb_buffer_pool_size parametro, vedere la documentazione di MySQL.

Le dimensioni della memoria fisica nella tabella seguente rappresentano la memoria ad accesso casuale (RAM) disponibile in gigabyte (GB) nel server flessibile Database di Azure per MySQL.

Dimensioni di calcolo	vCore	Dimensioni della memoria fisica (GB)	Valore predefinito (byte)	Valore minimo (byte)	Valore massimo (byte)
Possibilità di burst
Standard_B1s	1	1	134217728	33554432	268435456
Standard_B1ms	1	2	536870912	134217728	1073741824
Standard_B2s	2	4	2147483648	134217728	2147483648
Standard_B2ms	2	8	4294967296	134217728	5368709120
Standard_B4ms	4	16	12884901888	134217728	12884901888
Standard_B8ms	8	32	25769803776	134217728	25769803776
Standard_B12ms	12	48	51539607552	134217728	32212254720
Standard_B16ms	16	64	2147483648	134217728	51539607552
Standard_B20ms	20	80	64424509440	134217728	64424509440
Utilizzo generico
Standard_D2ads_v5	2	8	4294967296	134217728	5368709120
Standard_D2ds_v4	2	8	4294967296	134217728	5368709120
Standard_D4ads_v5	4	16	12884901888	134217728	12884901888
Standard_D4ds_v4	4	16	12884901888	134217728	12884901888
Standard_D8ads_v5	8	32	25769803776	134217728	25769803776
Standard_D8ds_v4	8	32	25769803776	134217728	25769803776
Standard_D16ads_v5	16	64	51539607552	134217728	51539607552
Standard_D16ds_v4	16	64	51539607552	134217728	51539607552
Standard_D32ads_v5	32	128	103079215104	134217728	103079215104
Standard_D32ds_v4	32	128	103079215104	134217728	103079215104
Standard_D48ads_v5	48	192	154618822656	134217728	154618822656
Standard_D48ds_v4	48	192	154618822656	134217728	154618822656
Standard_D64ads_v5	64	256	206158430208	134217728	206158430208
Standard_D64ds_v4	64	256	206158430208	134217728	206158430208
Business Critical
Standard_E2ds_v4	2	16	12884901888	134217728	12884901888
Standard_E2ads_v5, Standard_E2ds_v5	2	16	12884901888	134217728	12884901888
Standard_E4ds_v4	4	32	25769803776	134217728	25769803776
Standard_E4ads_v5, Standard_E4ds_v5	4	32	25769803776	134217728	25769803776
Standard_E8ds_v4	8	64	51539607552	134217728	51539607552
Standard_E8ads_v5, Standard_E8ds_v5	8	64	51539607552	134217728	51539607552
Standard_E16ds_v4	16	128	103079215104	134217728	103079215104
Standard_E16ads_v5, Standard_E16ds_v5	16	128	103079215104	134217728	103079215104
Standard_E20ds_v4	20	160	128849018880	134217728	128849018880
Standard_E20ads_v5, Standard_E20ds_v5	20	160	128849018880	134217728	128849018880
Standard_E32ds_v4	32	256	206158430208	134217728	206158430208
Standard_E32ads_v5, Standard_E32ds_v5	32	256	206158430208	134217728	206158430208
Standard_E48ds_v4	48	384	309237645312	134217728	309237645312
Standard_E48ads_v5, Standard_E48ds_v5	48	384	309237645312	134217728	309237645312
E64ds_v4 Standard	64	504	405874409472	134217728	405874409472
Standard_E64ads_v5 , Standard_E64ds_v5	64	512	412316860416	134217728	412316860416
Standard_E80ids_v4	80	504	405874409472	134217728	405874409472
Standard_E96ds_v5	96	672	541165879296	134217728	541165879296

innodb_file_per_table

MySQL archivia la tabella InnoDB in spazi di tabella diversi in base alla configurazione specificata durante la creazione della tabella. Lo spazio di tabella del sistema è l'area di archiviazione per il dizionario dei dati InnoDB. Uno spazio di tabella file per tabella contiene dati e indici per una singola tabella InnoDB e viene archiviato nel file system nel proprio file di dati. Il parametro del server innodb_file_per_table controlla questo comportamento.

Impostando innodb_file_per_table su OFF InnoDB crea tabelle nello spazio di tabella del sistema. Altrimenti, InnoDB crea tabelle in spazi di tabella di un file per tabella.

Database di Azure per MySQL : il server flessibile supporta un massimo di 8 terabyte (TB) in un singolo file di dati. Se le dimensioni del database sono superiori a 8 TB, è necessario creare la tabella nello innodb_file_per_table spazio tabelle. Se si dispone di una singola dimensione di tabella maggiore di 8 TB, è consigliabile usare la tabella di partizione.

innodb_log_file_size

Il valore di innodb_log_file_size è la dimensione (in byte) di ogni file di log in un gruppo di log. Le dimensioni combinate dei file di log (innodb_log_file_size innodb_log_files_in_group * ) non possono superare un valore massimo leggermente inferiore a 512 GB.

Una dimensione del file di log più grande è migliore per le prestazioni, ma lo svantaggio è che il tempo di ripristino dopo un arresto anomalo è elevato. È necessario bilanciare il tempo di ripristino per l'evento raro di un arresto anomalo rispetto alla massimizzazione della velocità effettiva durante le operazioni di picco. Una dimensione del file di log più grande può comportare tempi di riavvio più lunghi.

È possibile configurare innodb_log_size su 256 megabyte (MB), 512 MB, 1 GB o 2 GB per Database di Azure per MySQL - Server flessibile. Il parametro è statico e richiede un riavvio.

Nota

Se il innodb_log_file_size parametro è stato modificato dal valore predefinito, verificare se il valore di rimane per 0 30 secondi per evitare il ritardo del show global status like 'innodb_buffer_pool_pages_dirty' riavvio.

max_connections

Le dimensioni della memoria del server determinano il valore di max_connections. Le dimensioni della memoria fisica nella tabella seguente rappresentano la RAM disponibile, espressa in gigabyte, nel server flessibile Database di Azure per MySQL.

Dimensioni di calcolo	vCore	Dimensioni della memoria fisica (GB)	Default value	Valore minimo	Valore massimo
Possibilità di burst
Standard_B1s	1	1	85	10	171
Standard_B1ms	1	2	171	10	341
Standard_B2s	2	4	341	10	683
Standard_B2ms	2	4	683	10	1365
Standard_B4ms	4	16	1365	10	2731
Standard_B8ms	8	32	2731	10	5461
Standard_B12ms	12	48	4097	10	8193
Standard_B16ms	16	64	5461	10	10923
Standard_B20ms	20	80	6827	10	13653
Utilizzo generico
Standard_D2ads_v5	2	8	683	10	1365
Standard_D2ds_v4	2	8	683	10	1365
Standard_D4ads_v5	4	16	1365	10	2731
Standard_D4ds_v4	4	16	1365	10	2731
Standard_D8ads_v5	8	32	2731	10	5461
Standard_D8ds_v4	8	32	2731	10	5461
Standard_D16ads_v5	16	64	5461	10	10923
Standard_D16ds_v4	16	64	5461	10	10923
Standard_D32ads_v5	32	128	10923	10	21845
Standard_D32ds_v4	32	128	10923	10	21845
Standard_D48ads_v5	48	192	16384	10	32768
Standard_D48ds_v4	48	192	16384	10	32768
Standard_D64ads_v5	64	256	21845	10	43691
Standard_D64ds_v4	64	256	21845	10	43691
Business Critical
Standard_E2ds_v4	2	16	1365	10	2731
Standard_E2ads_v5, Standard_E2ds_v5	2	16	1365	10	2731
Standard_E4ds_v4	4	32	2731	10	5461
Standard_E4ads_v5, Standard_E4ds_v5	4	32	2731	10	5461
Standard_E8ds_v4	8	64	5461	10	10923
Standard_E8ads_v5, Standard_E8ds_v5	8	64	5461	10	10923
Standard_E16ds_v4	16	128	10923	10	21845
Standard_E16ads_v5, Standard_E16ds_v5	16	128	10923	10	21845
Standard_E20ds_v4	20	160	13653	10	27306
Standard_E20ads_v5, Standard_E20ds_v5	20	160	13653	10	27306
Standard_E32ds_v4	32	256	21845	10	43691
Standard_E32ads_v5, Standard_E32ds_v5	32	256	21845	10	43691
Standard_E48ds_v4	48	384	32768	10	65536
Standard_E48ads_v5, Standard_E48ds_v5	48	384	32768	10	65536
E64ds_v4 Standard	64	504	43008	10	86016
Standard_E64ads_v5, Standard_E64ds_v5	64	512	43691	10	87383
Standard_E80ids_v4	80	504	43008	10	86016
Standard_E96ds_v5	96	672	50000	10	100000

Quando le connessioni superano il limite, è possibile che venga visualizzato l'errore seguente: "ERRORE 1040 (08004): Troppe connessioni".

La creazione di nuove connessioni client a MySQL richiede tempo. Dopo aver stabilito queste connessioni, occupano risorse di database, anche quando sono inattive. La maggior parte delle applicazioni richiede molte connessioni di breve durata, che generano questa situazione. Il risultato è un minor numero di risorse disponibili per il carico di lavoro effettivo, con conseguente riduzione delle prestazioni.

Un pool di connessioni che riduce le connessioni inattive e riutilizza le connessioni esistenti consente di evitare questo problema. Per un'esperienza ottimale, è consigliabile usare un pool di connessioni come ProxySQL per gestire in modo efficiente le connessioni. Per informazioni sulla configurazione di ProxySQL, vedere questo post di blog.

Nota

ProxySQL è uno strumento della community open source. Microsoft la supporta nel modo migliore. Per ottenere supporto per la produzione con indicazioni autorevoli, contattare il supporto tecnico del prodotto ProxySQL.

innodb_strict_mode

Se viene visualizzato un errore simile a "Dimensioni della riga troppo grandi (> 8126)," potrebbe essere necessario disattivare il parametro del innodb_strict_mode server. Questo parametro non può essere modificato a livello globale a livello di server perché se le dimensioni dei dati delle righe sono maggiori di 8K, i dati vengono troncati senza errori. Questo troncamento può causare una potenziale perdita di dati. È consigliabile modificare lo schema in modo da adattare il limite di dimensioni della pagina.

È possibile impostare questo parametro a livello di sessione usando init_connect. Per altre informazioni, vedere Impostazione di parametri server non modificabili.

Nota

Se si dispone di un server di replica in lettura, l'impostazione su innodb_strict_mode OFF 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.

time_zone

Durante la distribuzione iniziale, un'istanza del server flessibile Database di Azure per MySQL include tabelle di sistema per informazioni sul fuso orario, ma queste tabelle non vengono popolate. È possibile popolare le tabelle del fuso orario chiamando la mysql.az_load_timezone stored procedure da uno strumento come la riga di comando di MySQL o MySQL Workbench. È anche possibile chiamare la stored procedure e impostare i fusi orari globali o a livello di sessione usando il portale di Azure o l'interfaccia della riga di comando di Azure.

binlog_expire_logs_seconds

In Database di Azure per MySQL - Server flessibile, il binlog_expire_logs_seconds 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. Il log binario contiene anche eventi per le istruzioni che potenzialmente potrebbero aver apportato modifiche. Il log binario viene usato principalmente per due scopi: 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 dell'eliminazione.

Se si desidera rendere persistenti i log binari per una durata più lunga, è possibile configurare il binlog_expire_logs_seconds parametro . Se binlog_expire_logs_seconds è impostato sul valore predefinito di 0, un log binario viene eliminato non appena l'handle viene liberato. Se il valore di è maggiore 0di binlog_expire_logs_seconds , il log binario viene eliminato dopo il numero di secondi configurato.

Database di Azure per MySQL: il server flessibile gestisce le funzionalità gestite, ad esempio l'eliminazione di backup e replica in lettura dei file binari, internamente. Quando si esegue la replica dei dati da Database di Azure per MySQL - Server flessibile, questo parametro deve essere impostato nel database primario per evitare l'eliminazione dei log binari prima che la replica legga dalle modifiche nel database primario. Se si imposta binlog_expire_logs_seconds su un valore superiore, i log binari non verranno eliminati abbastanza presto. Questo ritardo può causare un aumento della fatturazione dell'archiviazione.

event_scheduler

In Database di Azure per MySQL - Server flessibile, il parametro del event_scheduler server gestisce la creazione, la pianificazione e l'esecuzione di eventi. Ovvero, il parametro gestisce le attività eseguite in base a una pianificazione da un thread speciale dell'utilità di pianificazione eventi MySQL. 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.

Per i server MySQL versione 5.7, il parametro event_scheduler del server viene automaticamente disattivato quando viene avviato il backup e il parametro event_scheduler del server viene riattivato "ON" dopo il completamento del backup. In MySQL versione 8.0 per Database di Azure per MySQL - Server flessibile, il event_scheduler rimane invariato durante i backup. Per garantire operazioni più fluide, è consigliabile aggiornare i server MySQL 5.7 alla versione 8.0 usando un aggiornamento della versione principale.

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

Per altre informazioni sulla creazione di un evento, vedere la documentazione seguente sull'Utilità di pianificazione eventi nel manuale di riferimento di MySQL:

Configurare il parametro del server event_scheduler

Lo scenario seguente illustra un modo per usare il event_scheduler parametro in Database di Azure per MySQL - Server flessibile.

Per illustrare lo scenario, considerare l'esempio seguente di 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) |
| ``` |
| 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>;

Per eseguire un'istruzione SQL ogni ora senza fine:

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

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

Limiti

Per i server con disponibilità elevata configurata, quando si verifica il failover, è possibile che il parametro del event_scheduler server sia impostato su OFF. In questo caso, al termine del failover, configurare il parametro per impostare il valore su ON.

innodb_ft_user_stopword_table

innodb_ft_user_stopword_table è un parametro del server in MySQL che specifica il nome della tabella contenente parole non significative personalizzate per La ricerca full-text in InnoDB. La tabella deve trovarsi nello stesso database della tabella indicizzata full-text e la prima colonna deve essere di tipo VARCHAR. In Database di Azure per MySQL - Server flessibile, l'impostazione predefinita di sql_generate_invisible_primary_key=ON fa sì che tutte le tabelle senza una chiave primaria esplicita includano automaticamente una chiave primaria invisibile. Questo comportamento è in conflitto con i requisiti per innodb_ft_user_stopword_table, poiché la chiave primaria invisibile diventa la prima colonna della tabella, impedendone il funzionamento previsto durante la ricerca full-text. Per risolvere questo problema, è necessario impostare sql_generate_invisible_primary_key=OFF nella stessa sessione prima di creare la tabella delle parole non significative personalizzata. Ad esempio:

SET sql_generate_invisible_primary_key = OFF;
CREATE TABLE my_stopword_table (
    stopword VARCHAR(50) NOT NULL
);
INSERT INTO my_stopword_table (stopword) VALUES ('and'), ('or'), ('the');

In questo modo, la tabella stopword soddisfa i requisiti di MySQL e consente il corretto funzionamento delle parole non significative personalizzate.

Parametri del server non modificabili

Il riquadro Parametri server nel portale di Azure mostra sia i parametri modificabili che non modificabili del server. I parametri del server non modificabili non sono disponibili. È possibile configurare un parametro server non modificabile a livello di sessione usando init_connect nella portale di Azure o nell'interfaccia della riga di comando di Azure.

Condividi tramite

Parametri del server in Database di Azure per MySQL - Server flessibile

Che cosa sono i parametri del server?

Elenco di parametri del server configurabili

lower_case_table_names

innodb_tmpdir

log_bin_trust_function_creators

innodb_buffer_pool_size

innodb_file_per_table

innodb_log_file_size

max_connections

innodb_strict_mode

time_zone

binlog_expire_logs_seconds

event_scheduler

Configurare il parametro del server event_scheduler

Limiti

innodb_ft_user_stopword_table

Parametri del server non modificabili

Commenti e suggerimenti

Risorse aggiuntive

Condividi tramite

Parametri del server in Database di Azure per MySQL - Server flessibile

Che cosa sono i parametri del server?

Elenco di parametri del server configurabili

lower_case_table_names

innodb_tmpdir

log_bin_trust_function_creators

innodb_buffer_pool_size

innodb_file_per_table

innodb_log_file_size

max_connections

innodb_strict_mode

time_zone

binlog_expire_logs_seconds

event_scheduler

Configurare il parametro del server event_scheduler

Limiti

innodb_ft_user_stopword_table

Parametri del server non modificabili

Contenuto correlato

Commenti e suggerimenti

Risorse aggiuntive