Ajánlott eljárások az Azure Database for MySQL – Rugalmas kiszolgáló hibaelhárításához
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?
Az alábbi szakaszok segítségével zökkenőmentesen futtathatja rugalmas Azure Database for MySQL-kiszolgálói adatbázisait, és ezeket az információkat vezérelve biztosíthatja, hogy a sémák optimálisan legyenek megtervezve, és a lehető legjobb teljesítményt nyújthassa az alkalmazások számára.
Indexek számának ellenőrzése
Egy forgalmas adatbázis-környezetben magas I/O-használat figyelhető meg, ami a gyenge adatelérési minták mutatója lehet. A nem használt indexek negatív hatással lehetnek a teljesítményre, mivel lemezterületet és gyorsítótárat használnak fel, és lelassítják az írási műveleteket (IN Standard kiadás RT/ DELETE/ UPDATE). A nem használt indexek szükségtelenül több tárhelyet használnak fel, és növelik a biztonsági mentés méretét.
Mielőtt eltávolít egy indexet, mindenképpen gyűjtsön elegendő információt annak ellenőrzéséhez, hogy már nincs-e használatban. Ez az ellenőrzés segíthet elkerülni, hogy véletlenül eltávolítson egy olyan indexet, amely csak negyedévente vagy évente fut. Érdemes megfontolni azt is, hogy az index az egyediség vagy a rendezés kikényszerítésére szolgál-e.
Megjegyzés:
Ne felejtse el rendszeresen áttekinteni az indexeket, és a táblaadatok módosítása alapján végezze el a szükséges frissítéseket.
SELECT object_schema, object_name, index_name FROM performance_schema.table_io_waits_summary_by_index_usage WHERE index_name IS NOT NULL AND count_star = 0 ORDER BY object_schema, object_name;
(vagy)
use information_schema; select tables.table_name, statistics.index_name, statistics.cardinality, tables.table_rows from tables join statistics on (statistics.table_name = tables.table_name and statistics.table_schema = '<YOUR DATABASE NAME HERE>' and ((tables.table_rows / statistics.cardinality) > 1000));
A kiszolgáló legforgalmasságú indexeinek listázása
A következő lekérdezés kimenete az adatbázis-kiszolgáló összes táblájának és sémájának leggyakrabban használt indexeiről nyújt információt. Ez az információ hasznos lehet az egyes indexek írási és olvasási arányának, valamint az olvasások késési számának, valamint az egyéni írási műveleteknek a azonosításában, ami azt jelezheti, hogy további hangolásra van szükség az alapul szolgáló táblához és a függő lekérdezésekhez.
SELECT
object_schema AS table_schema,
object_name AS table_name,
index_name, count_star AS all_accesses,
count_read,
count_write,
Concat(Truncate(count_read / count_star * 100, 0), ':',
Truncate(count_write / count_star * 100, 0)) AS read_write_ratio,
count_fetch AS rows_selected ,
count_insert AS rows_inserted,
count_update AS rows_updated,
count_delete AS rows_deleted,
Concat(Round(sum_timer_wait / 1000000000000, 2), ' s') AS total_latency ,
Concat(Round(sum_timer_fetch / 1000000000000, 2), ' s') AS select_latency,
Concat(Round(sum_timer_insert / 1000000000000, 2), ' s') AS insert_latency,
Concat(Round(sum_timer_update / 1000000000000, 2), ' s') AS update_latency,
Concat(Round(sum_timer_delete / 1000000000000, 2), ' s') AS delete_latency
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE index_name IS NOT NULL AND count_star > 0
ORDER BY sum_timer_wait DESC
Az elsődleges kulcs kialakításának áttekintése
A rugalmas Azure Database for MySQL-kiszolgáló az InnoDB-tárolómotort használja az összes nem ideiglenes táblához. Az InnoDB-vel az adatok egy fürtözött indexben tárolódnak egy B-Fa struktúrával. A tábla fizikailag az elsődleges kulcsértékek alapján van rendszerezve, ami azt jelenti, hogy a sorok az elsődleges kulcs sorrendjében vannak tárolva.
Az InnoDB-táblák minden másodlagos kulcsbejegyzése egy mutatót tartalmaz arra az elsődleges kulcsértékre, amelyben az adatokat tárolják. Más szóval a másodlagos indexbejegyzés tartalmazza annak az elsődleges kulcsértéknek a másolatát, amelyre a bejegyzés mutat. Ezért az elsődleges kulcsválasztás közvetlen hatással van a táblák tárolási többletterhelésére.
Ha egy kulcs tényleges adatokból (például felhasználónévből, e-mailből, SSN-ből stb.) származik, akkor természetes kulcsnak nevezzük. Ha egy kulcs mesterséges, és nem adatokból származik (például autoincremented egész szám), akkor szintetikus kulcsnak vagy helyettesítő kulcsnak nevezzük.
Általában ajánlott elkerülni a természetes elsődleges kulcsok használatát. Ezek a kulcsok gyakran nagyon szélesek, és hosszú értékeket tartalmaznak egy vagy több oszlopból. Ez súlyos tárolási többletterhelést okozhat, mivel az elsődleges kulcs értékét minden másodlagos kulcsbejegyzésbe átmásolja a rendszer. Emellett a természetes kulcsok általában nem követik az előre meghatározott sorrendet, ami jelentősen csökkenti a teljesítményt, és oldaltöredezettséghez ad okot a sorok beszúrásakor vagy frissítésekor. A problémák elkerülése érdekében használjon monoton módon növekvő helyettesítő kulcsokat a természetes kulcsok helyett. Az autoincrement (big)integer oszlop jó példa egy monoton módon növekvő helyettesítő kulcsra. Ha az oszlopok bizonyos kombinációjára van szüksége, legyen egyedi, deklarálja ezeket az oszlopokat egyedi másodlagos kulcsként.
Az alkalmazás létrehozásának kezdeti szakaszaiban előfordulhat, hogy nem gondolkodik előre, hogy elképzeljen egy olyan időpontot, amikor a táblázat két milliárd sorból áll. Ennek eredményeképpen dönthet úgy, hogy egy azonosító (elsődleges kulcs) oszlop adattípusához egy aláírt 4 bájtos egész számot használ. Ellenőrizze az összes tábla elsődleges kulcsát, és váltson a 8 bájtos egész szám (BIGINT) oszlopok használatára a nagy mennyiség vagy a növekedés lehetőségének megfelelően.
Megjegyzés:
Az adattípusokról és azok maximális értékeiről a MySQL referencia-kézikönyvében talál további információt az Adattípusok című témakörben.
Lefedő indexek használata
Az előző szakasz bemutatja, hogy a MySQL-ben lévő indexek hogyan vannak B-fákként rendszerezve, és egy fürtözött indexben a levélcsomópontok tartalmazzák az alapul szolgáló tábla adatlapjait. A másodlagos indexek B-fa struktúrával rendelkeznek, mint a fürtözött indexek, és definiálhatja őket egy táblában vagy nézetben egy fürtözött index vagy halom segítségével. A másodlagos index minden egyes indexsora tartalmazza a nemclustered kulcsértéket és egy sorkeresőt. Ez a lokátor a fürtözött index adatsorára mutat, vagy a kulcsértéket tartalmazó halomra. Ennek eredményeképpen a másodlagos indexet tartalmazó kereséseknek a gyökércsomóponttól kezdve az ágcsomópontokon át a megfelelő levélcsomópontig kell navigálniuk az elsődleges kulcs értékének használatához. A rendszer ezután végrehajt egy véletlenszerű I/O-olvasást az elsődleges kulcsindexen (ismét navigál a gyökércsomóponttól az ágcsomópontokon át a megfelelő levélcsomópontig) az adatsor lekéréséhez.
Az adatsor lekéréséhez használja a fedő indexet, amely tartalmazza a lekérdezéshez szükséges összes mezőt, hogy elkerülje ezt az extra véletlenszerű I/O-olvasást az elsődleges kulcsindexen. Ez a megközelítés általában előnyös az I/O-hoz kötött számítási feladatok és a gyorsítótárazott számítási feladatok esetében. Ezért ajánlott eljárásként használjon lefedési indexeket, mert a memóriában elférnek, és kisebbek és hatékonyabbak az olvasáshoz, mint az összes sor vizsgálata.
Fontolja meg például azt a táblát, amellyel megpróbálhatja megkeresni a vállalathoz 2000. január 1-je után csatlakozott összes alkalmazottat.
mysql> show create table employee\G
*************************** 1. row ***************************
Table: employee
Create Table: CREATE TABLE `employee` (
`empid` int(11) NOT NULL AUTO_INCREMENT,
`fname` varchar(10) DEFAULT NULL,
`lname` varchar(10) DEFAULT NULL,
`joindate` datetime DEFAULT NULL,
`department` varchar(10) DEFAULT NULL,
PRIMARY KEY (`empid`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=latin1
1 row in set (0.00 sec)`
`mysql> select empid, fname, lname from employee where joindate > '2000-01-01';
Ha egy EXPLAIN-tervet futtat ezen a lekérdezésen, megfigyelheti, hogy jelenleg nem használ indexeket, és egy olyan záradékot használ, amely csak az alkalmazotti rekordok szűrésére szolgál.
mysql> EXPLAIN select empid, fname, lname from employee where joindate > '2000-01-01'\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: employee
partitions: NULL
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 3
filtered: 33.33
Extra: Using where
1 row in set, 1 warning (0.01 sec)
Ha azonban hozzáad egy olyan indexet, amely a where záradék oszlopát fedi le, és az előre jelzett oszlopokkal együtt azt tapasztalja, hogy az index segítségével sokkal gyorsabban és hatékonyabban keresheti meg az oszlopokat.
mysql> CREATE INDEX cvg_idx_ex ON employee (joindate, empid, fname, lname);
Ha a EXPLAIN-tervet ugyanazon a lekérdezésen futtatja, az "Index használata" érték megjelenik az "Extra" mezőben, ami azt jelenti, hogy az InnoDB a lekérdezést a korábban létrehozott index használatával hajtja végre, amely ezt lefedő indexként megerősíti.
mysql> EXPLAIN select empid, fname, lname from employee where joindate > '2000-01-01'\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: employee
partitions: NULL
type: range
possible_keys: cvg_idx_ex
key: cvg_idx_ex
key_len: 6
ref: NULL
rows: 1
filtered: 100.00
Extra: Using where; Using index
1 row in set, 1 warning (0.01 sec)
Megjegyzés:
A lekérdezés megfelelő kiszolgálásához fontos, hogy a fedőindex oszlopainak megfelelő sorrendje legyen kiválasztva. Az általános szabály az, hogy először a szűrés oszlopait (WHERE záradék), majd a rendezést/csoportosítást (ORDER BY és GROUP BY) és végül az adatvetítést (Standard kiadás LECT) választja ki.
Az előző példában láthattuk, hogy a lekérdezések lefedő indexe hatékonyabb rekordlekérési útvonalakat biztosít, és optimalizálja a teljesítményt egy magas párhuzamos adatbázis-környezetben.
További lépések
A legfontosabb kérdésekre adott társválaszok megkereséséhez, illetve a kérdések közzétételéhez vagy megválaszolásához látogasson el a Stack Overflow webhelyre.