sql >> Database >  >> RDS >> Sqlserver

5 SQL-syntaxis en queryprincipes voor betere databasebewaking

Het toepassen van goede SQL-syntaxis en het schrijven van query's zal de efficiëntie van uw databasebewaking verbeteren en als gevolg daarvan uw algehele databaseprestaties verbeteren. Er zijn verschillende beproefde manieren om de databaseprestaties te verbeteren door middel van syntaxis en query-aanpassingen. We hebben er 5 uitgekozen om op te focussen.

1. CASE-uitdrukkingen

Hier volgen enkele praktische tips om de beste prestaties uit CASE-expressies te halen:

  • CASE-expressies verbeteren de prestaties door oude procedurele code te verplaatsen naar declaratieve code die vervolgens kan worden geoptimaliseerd. Gebruik voor standaard CASE-expressies , dat het gemakkelijkst te optimaliseren is. Voor uitgebreide CASE-expressies zijn hashing en andere technieken het nuttigst.
  • Omdat WANNEER clausules van links naar rechts worden getest, is het het beste om uw clausules zo te rangschikken dat de meest waarschijnlijke eerst worden vermeld. Dit vermindert de tijd die wordt besteed aan onnodig scannen.
  • De meeste optimizers houden ook rekening met overbodige tests door rekening te houden met de volgorde van uitvoering. Zodra een WHEN-clausule wordt uitgevoerd, is het niet nodig om die clausule opnieuw te testen. Veel optimalisatieprogramma's zijn echter niet goed in het lezen van geneste CASE-expressies, dus het is het beste om ze op één niveau af te vlakken.

2. Double-dipping en de raamclausule

In SQL betekent "double-dipping" dezelfde tabel meer dan eens bezoeken, wat uw zoekopdracht vertraagt. Probeer in het ideale geval al uw klussen te klaren in één tafelbezoek. Maar als dat niet mogelijk is, zijn er een paar manieren om de impact op de prestaties te verminderen.

Het gebruik van tijdelijke tabellen die zijn gemaakt van dezelfde basistabel die samengevoegd is, is echt niet de beste manier om double-dipping te voorkomen. Een betere oplossing is om de optimizer van uw SQL-engine te gebruiken om VIEW's weer te geven en de resultaten als een werktabel te delen.

Als je beperkt bent tot een minder-dan-stellaire optimizer, gebruik dan tijdelijke tabellen en doe het werk handmatig.

Hoewel de bovenstaande methoden volkomen acceptabel zijn, is de beste manier om double-dipping te voorkomen, het gebruik van de window-clausule, omdat de subclauses op dezelfde manier werken als subquery-functies. Bijvoorbeeld:

  • De clausule PARTITION BY is als een lokale GROUP BY die de tabel opsplitst in groepen.
  • De ORDER BY-clausule legt een gesorteerde volgorde op.
  • Het raamkozijn (ROW of RANGE) is als een lokale WHERE-clausule.

U kunt vensterfuncties optimaliseren door deze regels te volgen:

  • In de index sorteert u eerst op de kolommen van de clausule PARTITION BY en vervolgens op de kolommen die in de clausule ORDER BY worden gebruikt.
  • Voeg elke andere kolom toe waarnaar in de zoekopdracht wordt verwezen als opgenomen kolommen van de index.

3. Opgeslagen procedures gebruiken

Object-relationele mappers (ORM's) veroorzaken tal van prestatieproblemen wanneer ze hun eigen code genereren. Als u ORM's moet gebruiken, schrijf dan uw eigen opgeslagen procedures zodat de prestaties er niet onder lijden.

Er zijn veel manieren waarop het gebruik van opgeslagen procedures de prestaties verbetert, waaronder:

  • Ze pushen minder gegevens over het netwerk, dus transacties zijn sneller
  • Ze maken kortere gesprekken mogelijk
  • Opgeslagen procedures zijn gemakkelijker te traceren in profieltools
  • Omdat een opgeslagen procedure een echt object in uw database is, is het gemakkelijker om prestatiestatistieken te krijgen, waardoor het gemakkelijker wordt om prestatieproblemen te vinden
  • Hergebruik van uitvoeringsplan neemt toe
  • Ze maken het gemakkelijker om met randgevallen om te gaan en voegen controle- of wijzigingsvergrendeling toe
  • Opgeslagen procedures zijn niet kwetsbaar voor aanvallen met SQL-injecties

4. VERWIJDEREN en BIJWERKEN in batches

Het verwijderen of bijwerken van veel gegevens van een grote tabelscan kost veel bronnen omdat beide instructies als één transactie worden uitgevoerd. Dit is een prestatiemoordenaar, want als er een fout optreedt terwijl de transactie wordt uitgevoerd en u deze moet stoppen, moet het systeem de hele transactie terugdraaien. Het terugdraaien van grote hoeveelheden gegevens kost veel tijd en blokkeert andere transacties.

U kunt dit prestatieprobleem voorkomen door updates en verwijderingen in kleine batches uit te voeren. Wanneer u deze transacties in batches uitvoert en de transactie wordt afgebroken, is de terugdraaiing veel kleiner. Het terugdraaien van een kleine hoeveelheid gegevens duurt niet lang en andere transacties kunnen werken terwijl de batch op schijf wordt vastgelegd.

5. Haal niet meer kolommen op dan u nodig heeft

Een van de belangrijkste oorzaken van slecht presterende zoekopdrachten is het ophalen van vreemde kolommen. Vermijd praktijken die vaak resulteren in het retourneren van een buitensporig aantal kolommen. Houd het volgende in gedachten:

  • Onnodig gebruik van "SELECT *" in een zoekopdracht zal waarschijnlijk meer kolommen opleveren dan u nodig heeft. Dit is een verspilling van bronnen en vergrendelt bronnen van andere gebruikers. Het is vooral belangrijk om "SELECT *" niet willekeurig te gebruiken in kolomvormige SQL-databases.
  • Knip-en-plakwerk om code opnieuw te gebruiken kan resulteren in vreemde kolommen.
  • Als je een VIEW aanroept, kan het zijn dat je geneste kolommen krijgt. Verwijder slecht presterende zoekopdrachten om te controleren welke kolommen er zijn en verwijder te grote kolommen die u niet nodig hebt. Een goede indicatie dat je een probleem hebt, is dat je een WHERE-clausule met aanvullende voorwaarden en een FROM-clausule met extra outer joins hebt.

Dit zijn slechts enkele van de manieren waarop een zorgvuldige benadering van SQL-syntaxis en het schrijven van query's de databasebewaking kan verbeteren. Wees niet bang om andere te proberen. Een goed presterende database is de sleutel tot het behalen van zakelijke doelen in elke organisatie.


  1. Aan de slag met GearHost voor MySQL-databaseontwikkeling

  2. AWS Summits 2018:samenvatting van Chicago

  3. T-SQL voorwaardelijke bestelling op

  4. Strings splitsen:nu met minder T-SQL