Teljesítmény finomhangolása és adatbázisok karbantartása az Azure Database for MySQL-ben – Rugalmas kiszolgáló a sys_schema

  • Cikk

A következőkre vonatkozik: Azure Database for MySQL – Egykiszolgálós Azure Database for MySQL – Rugalmas kiszolgáló

Fontos

Az önálló Azure Database for MySQL-kiszolgáló a kivonási útvonalon van. Határozottan javasoljuk, hogy frissítsen rugalmas Azure Database for MySQL-kiszolgálóra. További információ a rugalmas Azure Database for MySQL-kiszolgálóra való migrálásról: Mi történik az önálló Azure Database for MySQL-kiszolgálóval?

A MySQL performance_schema, amely először a MySQL 5.5-ben érhető el, számos alapvető kiszolgálói erőforrást biztosít, például a memóriafoglalást, a tárolt programokat, a metaadatok zárolását stb. A performance_schema azonban több mint 80 táblát tartalmaz, és a szükséges információk beszerzéséhez gyakran össze kell illeszteni a táblákat a performance_schema, és a information_schema táblákat. A performance_schema és information_schema építve a sys_schema hatékony felhasználóbarát nézetgyűjteményt biztosít egy írásvédett adatbázisban, és teljes mértékben engedélyezve van a rugalmas Azure Database for MySQL-kiszolgáló 5.7-es verziójában.

Views of sys_schema.

A sys_schema 52 nézet található, és mindegyik nézet az alábbi előtagok egyikével rendelkezik:

  • Host_summary vagy IO: I/O-kkal kapcsolatos késések.
  • InnoDB: InnoDB pufferállapot és zárolások.
  • Memória: A gazdagép és a felhasználók memóriahasználata.
  • Séma: Sémával kapcsolatos információk, például automatikus növekmény, indexek stb.
  • Utasítás: Információk az SQL-utasításokról; ez lehet olyan utasítás, amely teljes táblavizsgálatot vagy hosszú lekérdezési időt eredményezett.
  • Felhasználó: Felhasználók által felhasznált és csoportosított erőforrások. Ilyenek például a fájl i/operációs rendszere, a kapcsolatok és a memória.
  • Várakozás: Gazdagép vagy felhasználó szerint csoportosított várakozási események.

Most nézzük meg a sys_schema néhány gyakori használati mintáját. Először is a használati mintákat két kategóriába csoportosítjuk: teljesítményhangolás és adatbázis-karbantartás.

Teljesítmény-finomhangolás

sys.user_summary_by_file_io

Az IO az adatbázis legdrágább művelete. Az átlagos I/O-késést a sys.user_summary_by_file_io nézet lekérdezésével deríthetjük ki. Az alapértelmezett 125 GB-os kiépített tárhellyel az IO-késés körülbelül 15 másodperc.

IO latency: 125 GB.

Mivel a rugalmas Azure Database for MySQL-kiszolgáló skálázza az IO-t a tárolás tekintetében, a kiépített tároló 1 TB-ra való növelése után az I/O-késésem 571 ms-ra csökken.

IO latency: 1TB.

sys.schema_tables_with_full_table_scans

A gondos tervezés ellenére sok lekérdezés még mindig teljes táblavizsgálatot eredményezhet. Az indexek típusaival és optimalizálásával kapcsolatos további információkért tekintse meg a következő cikket: A lekérdezési teljesítmény hibaelhárítása. A teljes táblavizsgálatok erőforrásigényesek, és csökkentik az adatbázis teljesítményét. A táblák teljes táblázatvizsgálattal való megkeresésének leggyorsabb módja a sys.schema_tables_with_full_table_scans nézet lekérdezése.

Full table scans.

sys.user_summary_by_statement_type

Az adatbázis teljesítményproblémáinak elhárítása érdekében hasznos lehet azonosítani az adatbázison belüli eseményeket, és a sys.user_summary_by_statement_type nézet használata egyszerűen csak a trükköt hajthatja végre.

Summary by statement.

Ebben a példában a rugalmas Azure Database for MySQL-kiszolgáló 53 percet töltött a lassú lekérdezési napló 44579-szeri kiürítésével. Ez hosszú idő és sok IOS. Ezt a tevékenységet csökkentheti a lassú lekérdezési napló letiltásával, vagy az Azure Portalra való lassú lekérdezési bejelentkezés gyakoriságának csökkentésével.

Database maintenance

sys.innodb_buffer_stats_by_table

[! FONTOS]

A nézet lekérdezése hatással lehet a teljesítményre. Javasoljuk, hogy ezt a hibaelhárítást csúcsidőn kívüli munkaidőben végezze el.

Az InnoDB pufferkészlet a memóriában található, és a DBMS és a tároló közötti fő gyorsítótár-mechanizmus. Az InnoDB pufferkészlet mérete a teljesítményszinthez van kötve, és csak akkor módosítható, ha másik termékváltozatot választ. Az operációs rendszer memóriájához hasonlóan a régi lapok is felcserélve lesznek, hogy helyet adjanak a frissebb adatoknak. Ha meg szeretné tudni, hogy mely táblák fogyasztják az InnoDB pufferkészlet memóriájának nagy részét, lekérdezheti a sys.innodb_buffer_stats_by_table nézetet.

InnoDB buffer status.

A fenti ábrán látható, hogy a rendszertáblákon és nézeteken kívül a mysqldatabase033 adatbázis minden táblája, amely az egyik WordPress-webhelyemet üzemelteti, 16 KB vagy 1 oldalnyi adatot foglal el a memóriában.

Sys.schema_unused_indexes &sys.schema_redundant_indexes

Az indexek kiváló eszközök az olvasási teljesítmény javítására, de a beszúrások és a tárolás további költségekkel járnak. Sys.schema_unused_indexes és sys.schema_redundant_indexes betekintést nyújtanak a nem használt vagy duplikált indexekbe.

Unused indexes.

Redundant indexes.

Összefoglalás

Összefoglalva, a sys_schema kiváló eszköz mind a teljesítmény finomhangolására, mind az adatbázis karbantartására. Mindenképpen használja ki ezt a funkciót a rugalmas Azure Database for MySQL-kiszolgálópéldányban.

További lépések

  • Ha társválaszt szeretne keresni a leginkább érintett kérdéseire, vagy új kérdést/választ szeretne közzétenni, látogasson el a Stack Overflow webhelyre.