Serverparametrar i Azure Database for MySQL – flexibel server
Den här artikeln innehåller överväganden och riktlinjer för att konfigurera serverparametrar i Azure Database for MySQL – flexibel server.
Kommentar
Den här artikeln innehåller referenser till termen slave, som Microsoft inte längre använder. När termen tas bort från programvaran tar vi bort den från den här artikeln.
Vad är serverparametrar?
MySQL-motorn innehåller många serverparametrar (kallas även variabler) som du kan använda för att konfigurera och finjustera motorbeteende. Vissa parametrar kan anges dynamiskt under körning. Andra är statiska och kräver en omstart av servern när du har angett dem.
I Azure Database for MySQL – flexibel server kan du ändra värdet för olika MySQL-serverparametrar med hjälp av Konfigurera serverparametrar i Azure Database for MySQL – flexibel server med hjälp av Azure Portal och Konfigurera serverparametrar i Azure Database for MySQL – Flexibel server med hjälp av Azure CLI för att matcha dina arbetsbelastningsbehov.
Konfigurerbara serverparametrar
Du kan hantera konfigurationen av en flexibel Azure Database for MySQL-server med hjälp av serverparametrar. Serverparametrarna konfigureras med standardvärdena och rekommenderade värden när du skapar servern. Fönstret Serverparametrar i Azure Portal visar både de modifierbara och icke-modifierbara parametrarna. De icke-modifierbara serverparametrarna är inte tillgängliga.
Listan över serverparametrar som stöds växer ständigt. Du kan använda Azure Portal för att regelbundet visa den fullständiga listan över serverparametrar och konfigurera värdena.
Om du ändrar en statisk serverparameter med hjälp av portalen måste du starta om servern för att ändringarna ska börja gälla. Om du använder automationsskript (via verktyg som Azure Resource Manager-mallar, Terraform eller Azure CLI) bör skriptet ha en etablering för att starta om tjänsten så att inställningarna börjar gälla, även om du ändrar konfigurationen som en del av skapandet.
Om du vill ändra en icke-modifierad serverparameter för din miljö kan du publicera en idé via communityns feedback eller rösta om feedbacken redan finns (vilket kan hjälpa oss att prioritera).
I följande avsnitt beskrivs gränserna för de vanliga serverparametrarna. Beräkningsnivån och storleken (virtuella kärnor) på servern avgör gränserna.
lower_case_table_names
För MySQL version 5.7 är 1
standardvärdet lower_case_table_names
för i Azure Database for MySQL – flexibel server. Även om det är möjligt att ändra värdet som stöds till 2
, är det inte tillåtet att återgå från 2
tillbaka till 1
. Om du vill ha hjälp med att ändra standardvärdet skapar du en supportbegäran.
För MySQL version 8.0+ kan du bara konfigurera lower_case_table_names
när du initierar servern. Läs mer. lower_case_table_names
Det är förbjudet att ändra inställningen när servern har initierats.
Värden som stöds för MySQL version 8.0 är 1
och 2
i Azure Database for MySQL – flexibel server. Standardvärdet är 1
. Om du vill ha hjälp med att ändra standardvärdet när servern skapas skapar du ett supportärende.
innodb_tmpdir
Du använder parametern innodb_tmpdir i Azure Database for MySQL – Flexibel server för att definiera katalogen för temporära sorteringsfiler som skapas under onlineåtgärder ALTER TABLE
som återskapas.
Standardvärdet innodb_tmpdir
för är /mnt/temp
. Den här platsen motsvarar den tillfälliga lagringen (SSD) och är tillgänglig i gibibyte (GiB) med varje serverberäkningsstorlek. Den här platsen är perfekt för åtgärder som inte kräver mycket utrymme.
Om du behöver mer utrymme kan du ange innodb_tmpdir
till /app/work/tmpdir
. Den här inställningen använder den tillgängliga lagringskapaciteten på din flexibla Azure Database for MySQL-server. Den här inställningen kan vara användbar för större åtgärder som kräver mer tillfällig lagring.
Tänk på att användningen resulterar /app/work/tmpdir
i långsammare prestanda jämfört med standardvärdet för tillfällig lagring (SSD). /mnt/temp
Gör valet baserat på de specifika kraven för åtgärderna.
Den information som tillhandahålls gäller för innodb_tmpdir
parametrarna innodb_temp_tablespaces_dir, tmpdir och slave_load_tmpdir där:
- Standardvärdet
/mnt/temp
är vanligt. - Den alternativa katalogen
/app/work/tmpdir
är tillgänglig för att konfigurera ökad tillfällig lagring, med en kompromiss i prestanda baserat på specifika driftskrav.
log_bin_trust_function_creators
I Azure Database for MySQL – flexibel server är binära loggar alltid aktiverade (det vill: log_bin
är inställt på ON
). Parametern log_bin_trust_function_creators
är som standard inställd ON
på flexibla servrar.
Det binära loggningsformatet är alltid ROW
, och anslutningar till servern använder alltid radbaserad binär loggning. Med radbaserad binär loggning finns inte säkerhetsproblem och binär loggning kan inte brytas, så du kan på ett säkert sätt tillåta log_bin_trust_function_creators
att kvar som ON
.
Om log_bin_trust_function_creators
är inställt på OFF
och du försöker skapa utlösare kan du få fel som liknar: "Du har inte superprivilegier och binär loggning är aktiverad (du kanske vill använda den mindre säkra log_bin_trust_function_creators
variabeln)."
innodb_buffer_pool_size
Mer information om parametern finns i innodb_buffer_pool_size
MySQL-dokumentationen.
Den fysiska minnesstorleken i följande tabell representerar det tillgängliga ramminnet (random-access memory), i gigabyte (GB) på din flexibla Azure Database for MySQL-server.
Beräkningsstorlek | Virtuella kärnor | Storlek på fysiskt minne (GB) | Standardvärde (byte) | Minsta värde (byte) | Maxvärde (byte) |
---|---|---|---|---|---|
Burstbar | |||||
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 |
Generell användning | |||||
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 |
Affärskritisk | |||||
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 |
Standard_E64ds_v4 | 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 lagrar InnoDB-tabellen i olika tabellområden baserat på den konfiguration som du angav när tabellen skapades. Systemtabellområdet är lagringsområdet för InnoDB-dataordlistan. En tabellyta för fil per tabell innehåller data och index för en enda InnoDB-tabell, och den lagras i filsystemet i sin egen datafil. Parametern innodb_file_per_table server styr det här beteendet.
Inställningen innodb_file_per_table
gör att OFF
InnoDB skapar tabeller i systemtabellområdet. Annars skapar InnoDB tabeller i tabellutrymmen för fil per tabell.
Azure Database for MySQL – Flexibel server stöder högst 8 terabyte (TB) i en enda datafil. Om databasstorleken är större än 8 TB bör du skapa tabellen i innodb_file_per_table
tabellområdet. Om du har en tabellstorlek som är större än 8 TB bör du använda partitionstabellen.
innodb_log_file_size
Värdet för innodb_log_file_size är storleken (i byte) för varje loggfil i en logggrupp. Loggfilernas sammanlagda storlek (innodb_log_file_size * innodb_log_files_in_group) får inte överskrida ett maximalt värde som är något mindre än 512 GB.
En större loggfilstorlek är bättre för prestanda, men nackdelen är att återställningstiden efter en krasch är hög. Du måste balansera återställningstiden för den sällsynta händelsen av en krasch jämfört med att maximera dataflödet under hög belastning. En större loggfilstorlek kan också resultera i längre omstartstider.
Du kan konfigurera innodb_log_size
till 256 MEGABYTE (MB), 512 MB, 1 GB eller 2 GB för Azure Database for MySQL – flexibel server. Parametern är statisk och kräver en omstart.
Kommentar
Om du har ändrat parametern innodb_log_file_size
från standardvärdet kontrollerar du om värdet show global status like 'innodb_buffer_pool_pages_dirty'
för stannar kvar i 0
30 sekunder för att undvika omstartsfördröjning.
max_connections
Serverns minnesstorlek avgör värdet max_connections
för . Den fysiska minnesstorleken i följande tabell representerar det tillgängliga RAM-minnet i gigabyte på din flexibla Azure Database for MySQL-server.
Beräkningsstorlek | Virtuella kärnor | Storlek på fysiskt minne (GB) | Standardvärde | Minvärde | Maxvärde |
---|---|---|---|---|---|
Burstbar | |||||
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 |
Generell användning | |||||
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 |
Affärskritisk | |||||
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 |
Standard_E64ds_v4 | 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 |
När anslutningar överskrider gränsen kan du få följande fel: "FEL 1040 (08004): För många anslutningar."
Det tar tid att skapa nya klientanslutningar till MySQL. När du har upprättat dessa anslutningar upptar de databasresurser, även när de är inaktiva. De flesta program begär många kortvariga anslutningar, vilket förvärrar den här situationen. Resultatet är färre resurser som är tillgängliga för din faktiska arbetsbelastning, vilket leder till sämre prestanda.
En anslutningspool som minskar inaktiva anslutningar och återanvänder befintliga anslutningar hjälper dig att undvika det här problemet. För bästa möjliga upplevelse rekommenderar vi att du använder en anslutningspool som ProxySQL för att effektivt hantera anslutningar. Mer information om hur du konfigurerar ProxySQL finns i det här blogginlägget.
Kommentar
ProxySQL är ett communityverktyg med öppen källkod. Microsoft stöder det på bästa sätt. Kontakta supporten för ProxySQL-produkten för att få produktionsstöd med auktoritativ vägledning.
innodb_strict_mode
Om du får ett felmeddelande som liknar "Radstorleken är för stor (> 8126)" kanske du vill inaktivera serverparametern innodb_strict_mode
. Det går inte att ändra den här parametern globalt på servernivå eftersom om raddatastorleken är större än 8 000 trunkeras data utan fel. Den här trunkeringen kan leda till potentiell dataförlust. Vi rekommenderar att du ändrar schemat så att det passar sidstorleksgränsen.
Du kan ange den här parametern på sessionsnivå med hjälp init_connect
av . Mer information finns i Ange icke-modifierbara serverparametrar.
Kommentar
Om du har en skrivskyddade replikserver kommer replikeringen att OFF
avbrytas om du anger innodb_strict_mode
på sessionsnivå på en källserver. Vi rekommenderar att du behåller parametern inställd på ON
om du har läsrepliker.
time_zone
Vid den första distributionen innehåller en Azure Database for MySQL – flexibel server-instans systemtabeller för tidszonsinformation, men dessa tabeller är inte ifyllda. Du kan fylla i tidszonstabellerna genom att anropa den mysql.az_load_timezone
lagrade proceduren från ett verktyg som MySQL-kommandoraden eller MySQL Workbench. Du kan också anropa den lagrade proceduren och ange tidszoner på global nivå eller sessionsnivå med hjälp av Azure Portal eller Azure CLI.
binlog_expire_logs_seconds
I Azure Database for MySQL – flexibel server anger parametern binlog_expire_logs_seconds
antalet sekunder som tjänsten väntar innan den binära loggfilen tas bort.
Den binära loggen innehåller händelser som beskriver databasändringar, till exempel åtgärder för att skapa tabeller eller ändringar i tabelldata. Den binära loggen innehåller också händelser för instruktioner som potentiellt kan ha gjort ändringar. Den binära loggen används huvudsakligen för två syften: replikering och dataåterställningsåtgärder.
Vanligtvis tas de binära loggarna bort så snart referensen är fri från tjänsten, säkerhetskopieringen eller replikuppsättningen. Om det finns flera repliker väntar de binära loggarna på att den långsammaste repliken ska läsa ändringarna innan de tas bort.
Om du vill spara binära loggar under en längre tid kan du konfigurera parametern binlog_expire_logs_seconds
. Om binlog_expire_logs_seconds
är inställt på standardvärdet för 0
tas en binär logg bort så snart referensen till den frigjorts. Om värdet binlog_expire_logs_seconds
för är större än 0
tas den binära loggen bort efter det konfigurerade antalet sekunder.
Azure Database for MySQL – Flexibel server hanterar hanterade funktioner, till exempel säkerhetskopiering och läsning av replikborttagning av binära filer internt. När du replikerar datautdata från Azure Database for MySQL – Flexibel server måste den här parametern anges i den primära för att undvika borttagning av binära loggar innan repliken läse från ändringarna i den primära. Om du anger binlog_expire_logs_seconds
ett högre värde tas inte de binära loggarna bort tillräckligt snart. Den fördröjningen kan leda till en ökning av lagringsfakturering.
event_scheduler
I Azure Database for MySQL – flexibel server event_scheduler
hanterar serverparametern att skapa, schemalägga och köra händelser. Parametern hanterar uppgifter som körs enligt ett schema av en särskild MySQL Event Scheduler-tråd. När parametern event_scheduler
är inställd på ON
visas Event Scheduler-tråden som en daemonprocess i utdata från SHOW PROCESSLIST
.
För MySQL version 5.7-servrar inaktiveras serverparametern event_scheduler
automatiskt "OFF" när säkerhetskopieringen initieras och serverparametern event_scheduler
aktiveras igen när säkerhetskopieringen har slutförts. I MySQL version 8.0 för Azure Database for MySQL – flexibel server påverkas inte event_scheduler under säkerhetskopieringar. För att säkerställa smidigare åtgärder rekommenderar vi att du uppgraderar dina MySQL 5.7-servrar till version 8.0 med hjälp av en större versionsuppgradering.
Du kan skapa och schemalägga händelser med hjälp av följande SQL-syntax:
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>;
Mer information om hur du skapar en händelse finns i följande dokumentation om Event Scheduler i referenshandboken för MySQL:
Konfigurera event_scheduler-serverparametern
Följande scenario illustrerar ett sätt att använda parametern event_scheduler
i Azure Database for MySQL – flexibel server.
För att demonstrera scenariot bör du överväga följande exempel på en enkel tabell:
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>;
Så här kör du en SQL-instruktion varje timme utan slut:
CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 HOUR
COMMENT 'Comment'
DO
<your statement>;
Så här kör du en SQL-instruktion varje dag utan slut:
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>;
Begränsningar
För servrar med hög tillgänglighet konfigurerad är det möjligt att event_scheduler
serverparametern är inställd på OFF
. Om detta inträffar, när redundansväxlingen är klar, konfigurerar du parametern för att ange värdet till ON
.
innodb_ft_user_stopword_table
innodb_ft_user_stopword_table
är en serverparameter i MySQL som anger namnet på tabellen som innehåller anpassade stoppord för Fulltextsökning i InnoDB. Tabellen måste finnas i samma databas som den indexerade fulltexttabellen och dess första kolumn måste vara av typen VARCHAR
. I Azure Database for MySQL – flexibel server gör standardinställningen sql_generate_invisible_primary_key=ON
att alla tabeller utan en explicit primärnyckel automatiskt inkluderar en osynlig primärnyckel. Det här beteendet står i konflikt med kraven för innodb_ft_user_stopword_table
, eftersom den osynliga primärnyckeln blir den första kolumnen i tabellen, vilket hindrar den från att fungera som avsett under fulltextsökning. För att lösa det här problemet måste du ange sql_generate_invisible_primary_key=OFF
i samma session innan du skapar den anpassade stopword-tabellen. Till exempel:
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');
Detta säkerställer att stopword-tabellen uppfyller MySQL:s krav och tillåter att anpassade stoppord fungerar korrekt.
Icke-modifierbara serverparametrar
Fönstret Serverparametrar i Azure Portal visar både de modifierbara och icke-modifierbara serverparametrarna. De icke-modifierbara serverparametrarna är inte tillgängliga. Du kan konfigurera en icke-modifierad serverparameter på sessionsnivå med hjälp init_connect
av i Azure Portal eller Azure CLI.