olet uudessa työssäsi tietokannan ylläpitäjänä tai Datainsinöörinä ja juuri eksyit yrittäen selvittää, mitä nämä hullun näköiset kyselyt tarkoittavat ja tekevät. Miksi liittymiä on 5 ja miksi ORDER BY käytetään alaryhmässä ennen kuin yhtäkään liittymistä edes tapahtuu? Muista, että sinut palkattiin syystä-todennäköisesti tämä syy liittyy myös moniin mutkikkaisiin kyselyihin, joita on luotu ja muokattu viime vuosikymmenen aikana.
EXPLAIN hakusana on käytössä eri SQL-tietokannoissa ja antaa tietoa siitä, miten SQL-tietokantasi suorittaa kyselyn. MySQL: ssä EXPLAIN voidaan käyttää SELECTINSERTDELETEREPLACE, ja UPDATE. Yksinkertaiselle kyselylle se näyttäisi seuraavanlaiselta:
EXPLAIN SELECT * FROM foo WHERE foo.bar = 'infrastructure as a service' OR foo.bar = 'iaas';tavallisen tulosulostuloksen sijaan MySQL esittäisi lausekkeen suoritussuunnitelmansa selittämällä, mitkä prosessit tapahtuvat missäkin järjestyksessä lausetta suoritettaessa.
Huomautus: Jos EXPLAIN ei toimi sinulle, tietokannan Käyttäjällä ei välttämättä ole SELECT etuoikeutta taulukoihin tai näkymiin, joita käytät lausunnossasi.
EXPLAIN on loistava työkalu hitaiden kyselyiden nopeaan korjaamiseen. Vaikka se voi varmasti auttaa sinua, se ei poista tarvetta rakenteelliseen ajatteluun ja hyvään yleiskuvaan käytössä olevista tietomalleista. Usein yksinkertaisin korjaus ja nopein neuvo on lisätä indeksi tietyn taulukon sarakkeisiin, jos niitä käytetään monissa kyselyissä, joissa on suorituskykyyn liittyviä kysymyksiä. Varo kuitenkin, Älä käytä liikaa indeksejä, koska se voi olla haitallista. Indeksin ja taulukon lukeminen on järkevää vain, jos taulukossa on merkittävä määrä rivejä ja tarvitset vain muutaman datapisteen. Jos olet hakemassa valtava tulosjoukko taulukosta ja kyselet eri sarakkeita usein, indeksi jokaisen sarakkeen ei ole järkevää ja haittaa suorituskykyä enemmän kuin se auttaa. Saat lisätietoja indeksin vs no indeksin todellisista laskelmista, Lue suorituskyvyn arviointi virallisessa MySQL-dokumentaatiossa.
asioita, joita haluat välttää aina, kun se on mahdollista ja sovellettavissa, ovat lajittelu ja laskelmat kyselyissä. Jos luulet, ettet voi välttää laskelmia kyselyissäsi: kyllä, voit. Kirjoita tulosjoukko jonnekin muualle ja laske datapisteesi kyselyn ulkopuolella, se rasittaa tietokantaa vähemmän ja on siten yleisesti parempi sovelluksellesi. Varmista vain, että dokumentoit, miksi lasket sovelluksen sisällä sen sijaan, että SQL: ssä tuotettu tulos tuotettaisiin heti. Muuten seuraava tietokannan ylläpitäjä tai kehittäjä tulee mukaan ja on loistava ajatus käyttää laskelman sisällä kyselyn tapaan, ”oh katso, edeltäjäni ei edes tiennyt, että voit tehdä sen SQL!”Jotkut kehittäjäryhmät, joilla ei vielä ole ollut väistämätöntä kuolevien tietokantojen ongelmaa, saattavat käyttää kyselyssä laskelmia päivämäärien tai vastaavien datapisteiden lukumäärien eroista.
yleinen nyrkkisääntö SQL-kyselyissä on seuraava:
ole tarkka ja luo vain tarvitsemasi tulokset.
tarkastetaan hieman monimutkaisempi kysely…
SELECT site_options.domain, sites_users.user, site_taxes.monthly_statement_fee, site.name, AVG(price) AS average_product_price FROM sites_orders_products, site_taxes, site, sites_users, site_options WHERE site_options.site_id = site.id AND sites_users.id = site.user_id AND site_taxes.site_id = site.id AND sites_orders_products.site_id = site.id GROUP BY site.id ORDER BY site.date_modified desc LIMIT 5;+-----------------------------+-----------------------------+-----------------------+------------------------------------------+-----------------------+| domain | user | monthly_statement_fee | name | average_product_price |+-----------------------------+-----------------------------+-----------------------+------------------------------------------+-----------------------+| www.xxxxxxxxxxxxxxxxxxx.com | [email protected] | 0.50 | xxxxxxxxxxxxxxxxxxxxx | 3.254781 || www.xxxxxxxxxxx.com | [email protected] | 0.50 | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | 9.471022 || | [email protected] | 0.00 | xxxxxxxxxxxxxxxxx | 8.646297 || | [email protected] | 0.00 | xxxxxxxxxxxxxxx | 9.042460 || | [email protected] | 0.00 | xxxxxxxxxxxxxxxxxx | 6.679182 |+-----------------------------+-----------------------------+-----------------------+------------------------------------------+-----------------------+5 rows in set (0.00 sec)…ja sen EXPLAIN lähtö.
+------+-------------+---------------------------------+--------+-----------------+---------------+---------+---------------------------------+------+-----------+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |+------+-------------+---------------------------------+--------+-----------------+---------------+---------+---------------------------------+------+-----------+| 1 | SIMPLE | sites | index | PRIMARY,user_id | PRIMARY | 4 | NULL | 858 | Using temporary; Using filesort || 1 | SIMPLE | sites_options | ref | site_id | site_id | 4 | service.sites.id | 1 | || 1 | SIMPLE | sites_taxes | ref | site_id | site_id | 4 | service.sites.id | 1 | || 1 | SIMPLE | sites_users | eq_ref | PRIMARY | PRIMARY | 4 | service.sites.user_id | 1 | || 1 | SIMPLE | sites_orders_products | ref | site_id | site_id | 4 | service.sites.id | 4153 | |//+------+-------------+---------------------------------+--------+-----------------+---------------+---------+---------------------------------+------+-----------+5 rows in set (0.00 sec)EXPLAIN tuloste, jossa ongelmien tunnistamiseen tarvitaan erityistä huomiota lihavoituina ovat:
- tunnus (kyselyn tunnus)
- select_type (lausumistyyppi)
- taulukko (viittaustyyppi)
- tyyppi (liittymistyyppi)
- possible_keys (mitä avaimia olisi voitu käyttää)
- avain (avainta käytetty)
- avain_len (käytetyn avaimen pituus)
- ref (sarakkeita verrattu indeksiin)
- rivit (haettujen rivien määrä)
- extra (lisätietoja)
mitä suurempi hakurivien määrä, sitä parempi indeksien ja kyselyn tarkkuuden optimointitason on oltava suorituskyvyn maksimoimiseksi. Ylimääräinen sarake näyttää mahdolliset toimet, joihin voit keskittyä parantaaksesi kyselyäsi tarvittaessa.
Näytä Varoitukset;
Jos kysely, jota käytit EXPLAIN ei jäsenny oikein, voit kirjoittaa SHOW WARNINGS; MySQL-kyselyeditoriisi näyttämään tiedot viimeisestä suoritetusta lausekkeesta, joka ei ollut diagnostinen, eli se ei näytä tietoja lausekkeista, kuten SHOW FULL PROCESSLIST;. Vaikka se ei voi antaa kunnollista kyselyn suoritussuunnitelmaa, kuten EXPLAIN tekee, se saattaa antaa vihjeitä niistä kyselyn palasista, joita se voisi käsitellä. Sanotaan, että käytämme kyselyä EXPLAIN SELECT * FROM foo WHERE foo.bar = 'infrastructure as a service' OR foo.bar = 'iaas'; mistä tahansa tietopankista, jolla ei varsinaisesti ole taulukkoa foo. MySQL-lähtö olisi:
ERROR 1146 (42S02): Table 'db.foo' doesn't existJos kirjoitetaan SHOW WARNINGS; tuloste on seuraava:
+-------+------+-------------------------------------+| Level | Code | Message |+-------+------+-------------------------------------+| Error | 1146 | Table 'db.foo' doesn't exist |+-------+------+-------------------------------------+1 row in set (0.00 sec)kokeillaan tätä tahallisella syntaksivirheellä.
EXPLAIN SELECT * FROM foo WHERE name = ///;tästä saadaan seuraavat varoitukset:
> SHOW WARNINGS;+-------+------+---------------------------------------------------------------------+| Level | Code | Message |+-------+------+---------------------------------------------------------------------+| Error | 1064 | You have an error in your SQL syntax; (...) near '///' at line 1 |+-------+------+---------------------------------------------------------------------+tämä varoitustulos on melko suoraviivainen ja näkyy MySQL: n tulosulostuloksena heti, mutta monimutkaisemmissa kyselyissä, jotka eivät jäsenny, on vielä mahdollista katsoa, mitä niissä kyselytuloksissa tapahtuu, jotka voidaan jäsentää. SHOW WARNINGS; sisältää erityisiä merkkejä, joista voi saada hyödyllistä tietoa, kuten:
-
<index_lookup>(query fragment): indeksihaku tapahtuisi, jos kysely olisi jäsennetty oikein -
<if>(condition, expr1, expr2): an if condition is occuring in this specific part of the query -
<primary_index_lookup>(query fragment): an index lookup would be happening via primary key -
<temporary table>: sisäinen taulukko luotaisiin tähän väliaikaisten tulosten tallentamiseksi, esimerkiksi alijonoissa ennen liittymistä
, jotta saadaan lisätietoja näistä erikoismerkeistä, Lue laajennettu selittää esitysmuoto virallisessa MySQL dokumentaatio.
pitkän aikavälin korjaus
on useita tapoja korjata tietokannan huonon suorituskyvyn perimmäinen syy. Ensimmäisenä tarkastellaan tietomallia, ts. miten tiedot on jäsennetty ja käytätkö oikeaa tietokantaa? Monille tuotteille SQL-tietokanta on ihan hyvä. Yksi tärkeä asia on muistaa aina erottaa käyttöoikeuslokit tavallisesta tuotantotietokannasta, mitä ei valitettavasti tapahdu monissa yrityksissä. Useimmiten näissä tapauksissa, yritys aloitti pieni, kasvoi isompi, ja pohjimmiltaan edelleen käyttää samaa tietokantaa, mikä tarkoittaa, että ne käyttävät samaa tietokantaa sekä kirjaamisen toimintoja sekä muita tapahtumia. Tämä heikentää merkittävästi yleistä suorituskykyä, varsinkin kun yhtiö kasvaa isommaksi. Siksi on erittäin tärkeää luoda tietomalli, joka sopii ja on kestävä.
tietomalli
tietomallin valitseminen paljastaa todennäköisesti myös oikean tietokannan(tietokantojen) muodon. Ellei tuote on hyvin yksinkertainen, sinulla on todennäköisesti useita tietokantoja useita käyttötapauksia varten-jos haluat näyttää lähellä reaaliaikaisia numeroita käyttöoikeuslokeja varten, haluat todennäköisesti erittäin suorituskykyisen tietovaraston, kun taas säännölliset tapahtumat saattavat tapahtua SQL-tietokannan kautta, ja sinulla saattaa olla graafitietokanta, joka kerää molempien tietokantojen asiaankuuluvat tietopisteet suosittelijamoottoriin.
kokonaistuotteen ohjelmistoarkkitehtuuri on aivan yhtä tärkeä kuin itse tietokanta, sillä huono muotoilu aiheuttaa tässä pullonkauloja, jotka menevät tietokantaa kohti ja hidastavat kaikkea sekä ohjelmistopuolelta että siitä, mitä tietokannasta voi tuottaa. Sinun täytyy valita, ovatko säiliöt oikeat tuotteellesi, onko monoliitti parempi tapa käsitellä asioita, Haluatko olla ydin monoliitti, jossa on useita mikrospalveluja, jotka kohdistuvat muihin toimintoihin muualla ja miten käytät, keräät, käsittelet ja tallennat tietoja.
laitteisto
aivan yhtä tärkeä kuin yleinen rakenteesi, laitteistosi on keskeinen osa tietokantasi suorituskykyä. Exoscale tarjoaa erilaisia instanssivaihtoehtoja, joita voit käyttää tapahtuman ja tallennusmäärän sekä halutun vasteajan mukaan.
on ratkaisevan tärkeää määrittää hakemuksesi huippuajat ja siten tietää, milloin hitaammat hallinnolliset kyselyt kannattaa jättää pois, jos mahdollista. Levyn I / O-ja verkkotilastot on otettava huomioon myös suunniteltaessa tietokantatapahtumien ja analytiikan ajoitusta.
Yhteenveto
yhteenvetona voidaan todeta, että tässä ovat pitkän aikavälin suorituskyvyn pääkohdat tiivistettynä:
- luo kestävä tietomalli, joka sopii yrityksesi tarpeisiin
- valitse oikea tietokantamuoto
- käytä tuotettasi vastaavaa ohjelmistoarkkitehtuuria
- käy läpi säännöllisiä iteraatioita kyselyjesi rakenteen tarkastelusta ja käytä
EXPLAINmutkikkaammista, optimoi käyttö valitsemillesi tietokannoille, myös suhteessa tietokantapäivityksiin ja miten ne voisivat vaikuttaa sinuun - valitse sovelluksesi ja tietokantasi tarpeisiin parhaiten soveltuvat esiintymät suorituskyvyn ja kaistanleveyden mukaan