Tjänstnivåer för Azure Database for MySQL – flexibel server
GÄLLER FÖR:
Azure Database for MySQL – flexibel server
Du kan skapa en flexibel Azure Database for MySQL-serverinstans på någon av tre olika tjänstnivåer: Burstable, Generell användning och Affärskritisk. Tjänstnivåerna särskiljs av den underliggande VM SKU som används i B-serien, D-serien och E-serien. Valet av beräkningsnivå och storlek avgör det minne och de virtuella kärnor som är tillgängliga på servern. Samma lagringsteknik används på alla tjänstnivåer. Alla resurser etableras på instansnivå för Azure Database for MySQL– flexibel server. En server kan ha en eller flera databaser.
| Resurs/nivå | Burstbar | Generell användning | Affärskritisk |
|---|---|---|---|
| VM-serie | B-serien | Dadsv5-serienDdsv4-serien | Edsv4 Edsv5-serien*/Eadsv5-serien/ |
| Virtuella kärnor | 1, 2, 4, 8, 12, 16, 20 | 2, 4, 8, 16, 32, 48, 64 | 2, 4, 8, 16, 32, 48, 64, 80, 96 |
| Minne per virtuell kärna | Olika | 4 GiB | 8 GiB ** |
| Lagringsstorlek | 20 GiB till 16 TiB | 20 GiB till 16 TiB | 20 GiB till 16 TiB |
| Kvarhållningsperiod för databassäkerhetskopiering | 1 till 35 dagar | 1 till 35 dagar | 1 till 35 dagar |
** Med undantag för 64 80 och 96 virtuella kärnor, som har 504 GiB, 504 GiB respektive 672 GiB minne.
* Ev5-beräkning ger bästa prestanda bland andra VM-serier när det gäller QPS och svarstid. Läs mer om prestanda och regionstillgänglighet för Ev5-beräkning härifrån.
Om du vill välja en beräkningsnivå använder du följande tabell som utgångspunkt.
| Beräkningsnivå | Målbelastningar |
|---|---|
| Burstbar | Bäst för arbetsbelastningar som inte behöver hela processorn kontinuerligt. |
| Generell användning | De flesta företagsarbetsbelastningar som kräver balanserad beräkning och minne med skalbart I/O-dataflöde. Några exempel kan vara servrar som är värd för webb- och mobilappar och andra företagsprogram. |
| Affärskritisk | Databasarbetsbelastningar med höga prestanda som kräver minnesintern prestanda för snabbare transaktionsbearbetning och högre samtidighet. Exempel på det är servrar för att bearbeta realtidsdata och transaktionsappar eller analysappar med höga prestanda. |
När du har skapat en server kan beräkningsnivån, beräkningsstorleken och lagringsstorleken ändras. Beräkningsskalning kräver en omstart och tar mellan 60 och 120 sekunder, medan lagringsskalning inte kräver omstart. Du kan också oberoende justera kvarhållningsperioden för säkerhetskopior upp eller ned. Mer information finns i avsnittet Skala resurser .
Tjänstnivåer, storlek och servertyper
Beräkningsresurser kan väljas baserat på nivå och storlek. Detta avgör virtuella kärnor och minnesstorlek. virtuella kärnor representerar den underliggande maskinvarans logiska PROCESSOR.
Detaljerade specifikationer för tillgängliga servertyper är följande för Burstable:
| Beräkningsstorlek | Virtuella kärnor | Fysisk minnesstorlek (GiB) | Total minnesstorlek (GiB) | Maximalt antal IOPS som stöds | Max antal anslutningar | Temp Storage (SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_B1s | 1 | 1 | 1,1 | 320 | 171 | 0 |
| Standard_B1ms | 1 | 2 | 2,2 | 640 | 341 | 0 |
| Standard_B2s | 2 | 4 | 4.4 | 1280 | 683 | 0 |
| Standard_B2ms | 2 | 8 | 8.8 | 1 700 | 1365 | 0 |
| Standard_B4ms | 4 | 16 | 17,6 | 2400 | 2731 | 0 |
| Standard_B8ms | 8 | 32 | 35.2 | 3100 | 5461 | 0 |
| Standard_B12ms | 12 | 48 | 52.8 | 3800 | 8193 | 0 |
| Standard_B16ms | 16 | 64 | 70.4 | 4300 | 10923 | 0 |
| Standard_B20ms | 20 | 80 | 88 | 5000 | 13653 | 0 |
De detaljerade specifikationerna för de tillgängliga servertyperna är följande för generell användning:
| Beräkningsstorlek | Virtuella kärnor | Fysisk minnesstorlek (GiB) | Total minnesstorlek (GiB) | Maximalt antal IOPS som stöds | Max antal anslutningar | Temp Storage (SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_D2ads_v5 | 2 | 8 | 11 | 3200 | 1365 | 53 |
| Standard_D2ds_v4 | 2 | 8 | 11 | 3200 | 1365 | 53 |
| Standard_D4ads_v5 | 4 | 16 | 22 | 6400 | 2731 | 107 |
| Standard_D4ds_v4 | 4 | 16 | 22 | 6400 | 2731 | 107 |
| Standard_D8ads_v5 | 8 | 32 | 44 | 12800 | 5461 | 215 |
| Standard_D8ds_v4 | 8 | 32 | 44 | 12800 | 5461 | 215 |
| Standard_D16ads_v5 | 16 | 64 | 88 | 20000 | 10923 | 430 |
| Standard_D16ds_v4 | 16 | 64 | 88 | 20000 | 10923 | 430 |
| Standard_D32ads_v5 | 32 | 128 | 176 | 20000 | 21845 | 860 |
| Standard_D32ds_v4 | 32 | 128 | 176 | 20000 | 21845 | 860 |
| Standard_D48ads_v5 | 48 | 192 | 264 | 20000 | 32768 | 1290 |
| Standard_D48ds_v4 | 48 | 192 | 264 | 20000 | 32768 | 1290 |
| Standard_D64ads_v5 | 64 | 256 | 352 | 20000 | 43691 | 1720 |
| Standard_D64ds_v4 | 64 | 256 | 352 | 20000 | 43691 | 1720 |
De detaljerade specifikationerna för de tillgängliga servertyperna är följande för Affärskritisk:
| Beräkningsstorlek | Virtuella kärnor | Fysisk minnesstorlek (GiB) | Total minnesstorlek (GiB) | Maximalt antal IOPS som stöds | Max antal anslutningar | Temp Storage (SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_E2ds_v4 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E2ads_v5 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E4ds_v4 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E4ads_v5 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E8ds_v4 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E8ads_v5 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E16ds_v4 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E16ads_v5 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E20ds_v4 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E20ads_v5 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E32ds_v4 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E32ads_v5 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E48ds_v4 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E48ads_v5 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E64ds_v4 | 64 | 504 | 693 | 64000 | 86016 | 1224 |
| Standard_E64ads_v5 | 64 | 504 | 693 | 64000 | 86016 | 1224 |
| Standard_E80ids_v4 | 80 | 504 | 693 | 72000 | 86016 | 1224 |
| Standard_E2ds_v5 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E4ds_v5 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E8ds_v5 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E16ds_v5 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E20ds_v5 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E32ds_v5 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E48ds_v5 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E64ds_v5 | 64 | 512 | 704 | 64000 | 87383 | 1208 |
| Standard_E96ds_v5 | 96 | 672 | 924 | 80000 | 100000 | 2004 |
Minneshantering i Azure Database for MySQL – flexibel server
I MySQL spelar minnet en viktig roll i olika åtgärder, inklusive frågebearbetning och cachelagring. Azure Database for MySQL – flexibel server optimerar minnesallokering för MySQL-serverprocessen (mysqld), vilket säkerställer att den tar emot tillräckligt med minnesresurser för effektiv frågebearbetning, cachelagring, hantering av klientanslutningar och trådhantering. Läs mer om hur MySQL använder minne.
Fysisk minnesstorlek (GB)
Den fysiska minnesstorleken (GB) i tabellen nedan representerar det tillgängliga ramminnet (Random Access Memory) i gigabyte (GB) på din flexibla Azure Database for MySQL-server.
Total minnesstorlek (GB)
Azure Database for MySQL – flexibel server ger en total minnesstorlek (GB). Detta representerar det totala minnet som är tillgängligt för servern, vilket är en kombination av fysiskt minne och en uppsättning temporära SSD-komponenter för lagring. Den här enhetliga vyn är utformad för att effektivisera resurshanteringen, så att du kan fokusera på det totala minne som är tillgängligt för din Azure MySQL Server-process (mysqld). Måttet Minnesprocent (memory_percent) representerar procentandelen minne som upptas av Azure MySQL-serverprocessen (mysqld). Det här måttet beräknas från den totala minnesstorleken (GB). När måttet Minnesprocent till exempel visar värdet 60 innebär det att Azure MySQL Server-processen använder 60 % av den totala minnesstorleken (GB) som är tillgänglig på din flexibla Azure Database for MySQL-server.
MySQL Server (mysqld)
Azure MySQL-serverprocessen mysqld fungerar som huvudmotor för databasåtgärder. Vid start initieras totalt antal komponenter, till exempel InnoDB-buffertpoolen och trådcache, med hjälp av minne baserat på konfigurations- och arbetsbelastningskrav. Till exempel cachelagrar InnoDB-buffertpoolen data och index som används ofta för att förbättra frågekörningshastigheten, medan trådcachen hanterar klientanslutningstrådar. Läs mer.
InnoDB-lagringsmotor
Som MySQL:s standardlagringsmotor använder InnoDB minne för cachelagring av data som används ofta och hanterar interna strukturer som innodb-buffertpoolen och loggbufferten. InnoDB-buffertpoolen innehåller tabelldata och index i minnet för att minimera disk-I/O, vilket förbättrar prestandan. Parametern InnoDB Buffer Pool Size beräknas baserat på den fysiska minnesstorlek (GB) som är tillgänglig på servern. Läs mer om storleken på innoDB-buffertpoolen som är tillgänglig i Azure Database for MySQL – flexibel server.
Trådar
Klientanslutningar hanteras via dedikerade trådar som hanteras av anslutningshanteraren. Dessa trådar hanterar autentisering, frågekörning och resultathämtning för klientinteraktioner. Läs mer.
Mer information om tillgängliga beräkningsserier finns i dokumentationen för virtuella Azure-datorer för Burstable (B-serien), Ddsv4-serien i General Purpose Dadsv5-serien och Affärskritisk Eadsv5-serien i Edsv4/Edsv5-serien./
Prestandabegränsningar för burstbara serieinstanser
Kommentar
För beräkningsnivån Burstable (B-serien) om den virtuella datorn startas/stoppas eller startas om kan krediterna gå förlorade. Mer information finns i Vanliga frågor och svar om Burstable (B-serien).
Burstbar beräkningsnivå är utformad för att tillhandahålla en kostnadseffektiv lösning för arbetsbelastningar som inte kräver kontinuerlig full CPU kontinuerligt. Den här nivån är perfekt för icke-produktionsarbetsbelastningar, till exempel utvecklings-, mellanlagrings- eller testmiljöer. Den unika funktionen för den burstable beräkningsnivån är dess förmåga att "burst", det villa att använda mer än sin baslinje CPU-prestanda med upp till 100% av vCPU när arbetsbelastningen kräver det. Detta möjliggörs av en CPU-kreditmodell, som gör det möjligt för B-seriens instanser att ackumulera "CPU-krediter" under perioder med låg CPU-användning. Dessa krediter kan sedan användas under perioder med hög CPU-användning, vilket gör att instansen kan överskrida sin grundläggande CPU-prestanda.
Det är dock viktigt att observera att när en burstbar instans förbrukar sina CPU-krediter fungerar den med sin grundläggande CPU-prestanda. Till exempel är den grundläggande CPU-prestandan för en Standard_B1ms 20 % det vill säga 0,2 virtuella kärnor. Om Burstable-nivåservern kör en arbetsbelastning som kräver mer CPU-prestanda än basnivån, och den har förbrukat sina CPU-krediter, kan servern uppleva prestandabegränsningar och kan så småningom påverka olika systemåtgärder som Stop/Start/Restart för servern.
Kommentar
För servrar i beräkningsnivån Burstable (B-serien), till exempel Standard_B1s/Standard_B1ms/Standard_B2s, deras relativt mindre minnesstorlek för värden, kan det leda till krascher (slut på minne) under kontinuerlig arbetsbelastning, även om måttet memory_percent inte har nått 100 %.
På grund av den här begränsningen kan servern stöta på anslutningsproblem och systemåtgärder kan påverkas. I sådana situationer rekommenderar vi att du pausar arbetsbelastningen på servern för att ackumulera krediter enligt kreditbankmodellen i B-serien, eller att överväga att skala servern till högre nivåer som Generell användning eller Affärskritisk nivåer.
Även om beräkningsnivån Burstable erbjuder betydande kostnads- och flexibilitetsfördelar för vissa typer av arbetsbelastningar rekommenderas det därför inte för produktionsarbetsbelastningar som kräver konsekvent CPU-prestanda. Nivån Burstable stöder inte funktioner för att skapa läsrepliker och funktion för hög tillgänglighet . För sådana arbetsbelastningar och funktioner är andra beräkningsnivåer, till exempel generell användning eller Affärskritisk lämpligare.
Mer information om Azures processorkreditmodell i B-serien finns i B-seriens burstable-instanser och B-seriens CPU-kreditmodell.
Övervaka CPU-krediter på burstbar nivå
Att övervaka ditt CPU-kreditsaldo är avgörande för att upprätthålla optimala prestanda på beräkningsnivån Burstable. Azure Database for MySQL – flexibel server innehåller två viktiga mått relaterade till CPU-krediter. Det perfekta tröskelvärdet för att utlösa en avisering beror på dina specifika arbetsbelastnings- och prestandakrav.
Förbrukad CPU-kredit: Det här måttet anger antalet CPU-krediter som förbrukas av din instans. Genom att övervaka det här måttet kan du förstå cpu-användningsmönstren för din instans och hantera dess prestanda effektivt.
Återstående CPU-kredit: Det här måttet visar antalet cpu-krediter som återstår för din instans. Genom att hålla ett öga på det här måttet kan du förhindra att din instans försämrar prestandan på grund av att processorkrediterna har förbrukats. Om måttet återstående CPU-kredit sjunker under en viss nivå (till exempel mindre än 30 % av de totala tillgängliga krediterna) skulle detta tyda på att instansen riskerar att förbruka sina CPU-krediter om den aktuella CPU-belastningen fortsätter.
Mer information om hur du konfigurerar aviseringar för mått finns i den här guiden.
Lagring
Lagringen du etablerar är mängden lagringskapacitet som är tillgänglig för din flexibla server. Lagring används för databasfiler, temporära filer, transaktionsloggar och MySQL-serverloggarna. Det lägsta lagringsutrymmet som stöds är 20 GiB och det maximala är 16 TiB i alla tjänstnivåer. Lagringen skalas i steg om 1 GiB och kan skalas upp när servern har skapats.
Kommentar
Lagringen kan bara skalas upp, inte ned
Du kan övervaka din lagringsförbrukning i Azure-portalen (med Azure Monitor) med hjälp av måtten lagringsgräns, lagringsprocent och lagring som används. Mer information om mått finns i övervakningsartikeln .
Lagringsgränsen är nådd
När lagringsutrymmet som förbrukas på servern är nära att nå den etablerade gränsen försätts servern i skrivskyddat läge för att skydda förlorade skrivningar på servern. Servrar med mindre än 100 GiB-etablerat lagringsutrymme markeras som skrivskyddade om det kostnadsfria lagringsutrymmet är mindre än 5 % av den etablerade lagringsstorleken. Servrar med mer än 100 GiB-etablerat lagringsutrymme markeras skrivskyddat när det kostnadsfria lagringsutrymmet är mindre än 5 GiB.
Om du till exempel har etablerat 110 GiB lagringsutrymme och den faktiska användningen överskrider 105 GiB markeras servern som skrivskyddad. Om du har etablerat 5 GiB lagringsutrymme markeras servern som skrivskyddad när det kostnadsfria lagringsutrymmet når mindre än 256 MB.
Medan tjänsten försöker göra servern skrivskyddad blockeras alla nya skrivtransaktionsbegäranden och befintliga aktiva transaktioner fortsätter att köras. När servern är i skrivskyddat läge misslyckas alla efterföljande skrivåtgärder och transaktioner. Läsfrågor fortsätter att fungera oavbrutet.
Öka den etablerade lagringen på servern för att inaktivera det skrivskyddade läget. Du kan göra detta i Microsoft Azure-portalen eller Azure CLI. När den har ökat är servern redo att acceptera skrivtransaktioner igen.
Vi rekommenderar att du konfigurerar en avisering för att meddela dig när serverlagringen närmar sig tröskelvärdet så att du kan undvika att hamna i skrivskyddat tillstånd. Mer information finns i dokumentationen om aviseringsdokumentationen om hur du konfigurerar en avisering.
Lagringen växer automatiskt
Automatisk lagringsväxning hindrar servern från att få slut på lagring och blir skrivskyddad. Om automatisk lagringsbrytning är aktiverat växer lagringen automatiskt utan att påverka arbetsbelastningen. Automatisk lagringsbrytning är aktiverat som standard för alla nya servrar som skapas. För servrar med mindre än 100 GB etablerat lagringsutrymme ökas den etablerade lagringsstorleken med 5 GB när det kostnadsfria lagringsutrymmet understiger 10 % av det etablerade lagringsutrymmet. För servrar med mer än 100 GB allokerat lagringsutrymme ökas den allokerade lagringsstorleken med 5 % när det lediga lagringsutrymmet är mindre än 10 GB av den allokerade lagringsstorleken. Maximala lagringsgränser enligt informationen ovan gäller. Uppdatera serverinstansen för att se det uppdaterade lagringsutrymmet som etablerats under Inställningar på sidan Beräkning + lagring.
Om du till exempel har etablerat 1 000 GB lagringsutrymme och den faktiska användningen överstiger 990 GB ökas serverlagringsstorleken till 1 050 GB. Om du har etablerat 20 GB lagringsutrymme ökar också lagringsstorleken till 25 GB när mindre än 2 GB lagringsutrymme är kostnadsfritt.
Kom ihåg att lagring när den har skalats upp automatiskt och inte kan skalas ned.
Kommentar
Autogrow för lagring är standard aktiverat för en konfigurerad server med hög tillgänglighet och kan inte inaktiveras.
IOPS
Azure Database for MySQL – flexibel server stöder företablerad IOPS och autoskalning av IOPS. Läs mer. Minsta IOPS är 360 för alla beräkningsstorlekar och den maximala IOPS bestäms av den valda beräkningsstorleken. Mer information om maximal IOPS per beräkningsstorlek finns i tabellen.
Viktigt!
**Minsta IOPS är 360 för alla beräkningsstorlekar
**Maximal IOPS bestäms av den valda beräkningsstorleken.
Du kan övervaka din I/O-förbrukning i Azure-portalen (med Azure Monitor) med hjälp av måttet I/O-procent . Om du behöver mer IOPS än det maximala IOPS-värde som baseras på beräkning måste du skala serverns beräkning.
Företablerad IOPS
Azure Database for MySQL – flexibel server erbjuder företablerad IOPS, så att du kan allokera ett visst antal IOPS till din flexibla Azure Database for MySQL-serverinstans. Den här inställningen garanterar konsekventa och förutsägbara prestanda för dina arbetsbelastningar. Med företablerad IOPS kan du definiera en specifik IOPS-gräns för din lagringsvolym, vilket garanterar möjligheten att hantera vissa begäranden per sekund. Detta resulterar i en tillförlitlig och säker prestandanivå. Med företablerad IOPS kan du etablera ytterligare IOPS över IOPS-gränsen. Med den här funktionen kan du när som helst öka eller minska antalet IOPS som tillhandahålls baserat på dina arbetsbelastningskrav.
Autoskalning av IOPS
Hörnstenen i Azure Database for MySQL – flexibel server är dess förmåga att uppnå bästa möjliga prestanda för arbetsbelastningar på nivå 1, vilket kan förbättras genom att servern automatiskt skalar prestanda (IO) för sina databasservrar sömlöst beroende på arbetsbelastningsbehoven. Det här är en opt-in-funktion som gör det möjligt för användare att skala IOPS på begäran utan att behöva etablera en viss mängd I/O per sekund. Med funktionen Autoskala IOPS kan du nu njuta av kostnadsfri I/O-hantering i Azure Database for MySQL – flexibel server eftersom servern skalar upp eller ned IOPS automatiskt beroende på arbetsbelastningsbehov.
Med autoskalnings-IOPS betalar du bara för den I/O som servern använder och behöver inte längre etablera och betala för resurser som de inte använder fullt ut, vilket sparar både tid och pengar. Dessutom kan verksamhetskritiska nivå 1-program uppnå konsekventa prestanda genom att göra ytterligare I/O tillgängligt för arbetsbelastningen när som helst. Autoskalning av IOPS eliminerar den administration som krävs för att ge bästa möjliga prestanda till lägsta kostnad för kunder med flexibel Azure Database for MySQL-server.
Dynamisk skalning: IOPS för autoskalning justerar dynamiskt IOPS-gränsen för databasservern baserat på den faktiska efterfrågan på din arbetsbelastning. Detta säkerställer optimala prestanda utan manuella åtgärder eller konfiguration.
Hantering av arbetsbelastningstoppar: Med autoskalnings-IOPS kan din databas smidigt hantera arbetsbelastningstoppar eller fluktuationer utan att äventyra programmets prestanda. Den här funktionen säkerställer konsekvent svarstid även under perioder med hög användning.
Kostnadsbesparingar: Till skillnad från den företablerade IOPS där en fast IOPS-gräns har angetts och betalats för oavsett användning kan du med autoskalnings-IOPS endast betala för det antal I/O-åtgärder som du använder.
Backup
Tjänsten tar automatiskt säkerhetskopior av servern. Du kan välja en kvarhållningsperiod mellan 1 och 35 dagar. Läs mer om säkerhetskopior i artikeln om säkerhetskopiering och återställning.
Skala resurser
När du har skapat servern kan du oberoende ändra beräkningsnivå, beräkningsstorlek (virtuella kärnor och minne) och mängden lagringsutrymme samt kvarhållningsperioden för säkerhetskopior. Beräkningsstorleken kan skalas upp eller ned. Kvarhållningsperioden för säkerhetskopior kan skalas upp eller ned från 1 till 35 dagar. Lagringsstorleken kan bara ökas. Skalning av resurserna kan göras via portalen eller Azure CLI.
Kommentar
Lagringsstorleken kan bara ökas. Du kan inte gå tillbaka till en mindre lagringsstorlek efter ökningen.
När du ändrar beräkningsnivån eller beräkningsstorleken startas servern om för att den nya servertypen ska börja gälla. Under tiden då systemet växlar över till den nya servern kan inga nya anslutningar upprättas, och transaktioner som inte allokerats återställs. Det här fönstret varierar, men är i de flesta fall mellan 60 och 120 sekunder.
Skalning av lagring och ändring av kvarhållningsperioden för säkerhetskopior är onlineåtgärder och kräver ingen omstart av servern.
Prissättning
Den senaste prisinformationen finns på sidan med tjänstpriser. Om du vill se kostnaden för den konfiguration du vill använda visar Azure-portalen månadskostnaden på fliken Beräkning + lagring baserat på de alternativ du väljer. Om du inte har en Azure-prenumeration kan du använda priskalkylatorn för Azure för att få ett uppskattat pris. På webbplatsen för Priskalkylatorn för Azure väljer du Lägg till objekt, expanderar kategorin Databaser, väljer Azure Database for MySQL och Flexibel server som distributionstyp för att anpassa alternativen.
Om du vill optimera serverkostnaden kan du överväga följande tips:
- Skala ned beräkningsnivån eller beräkningsstorleken (virtuella kärnor) om beräkningen är underutnyttad.
- Överväg att byta till den burstbara beräkningsnivån om din arbetsbelastning inte behöver den fullständiga beräkningskapaciteten kontinuerligt från nivåerna Generell användning och Affärskritisk.
- Stoppa servern när den inte används.
- Minska kvarhållningsperioden för säkerhetskopior om en längre kvarhållning av säkerhetskopian inte krävs.
Relaterat innehåll
- Lär dig hur du skapar en flexibel Azure Database for MySQL-serverinstans i portalen.
- Lär dig mer om tjänstbegränsningar.