---
title: "Antalet SQL-satser - prestanda"
type: "forum-thread"
url: "https://www.webforum.nu/amne/databaser-sql/60778-antalet-sql-satser-prestanda"
topic: "Databaser & SQL"
topic_url: "https://www.webforum.nu/amne/databaser-sql"
author: "koltrasten"
published: "2002-11-30T22:34:40.000Z"
updated: "2002-12-01T20:03:58.000Z"
replies: 7
views: 258
page: 1
pages: 1
language: "sv-SE"
site: "webForum — webforum.nu"
rights: "Upphovsrätten till varje inlägg tillhör dess författare."
attribution: "Citera som: webForum, https://www.webforum.nu/amne/databaser-sql/60778-antalet-sql-satser-prestanda"
---

# Antalet SQL-satser - prestanda

## #1 — koltrasten, 2002-11-30T22:34Z

Hej!
Hur stor skillnad gör det prestandamässigt, med många SQL-satser. Jag har ett script som jag egentligen kan lösa med **1** SQL-sats men av säkerhetsskäl och överskådlighet borde det vara bättre att använda loopar och då blir det **12** stycken.

Gör det någon stor skillnad? Laddningstid, bandbredd, prestanda, etc.

(**ASP+mySQL**)

Permalänk: https://www.webforum.nu/p/60778

## #2 — koltrasten, 2002-12-01T09:05Z

Ingen som kan? :OO

Permalänk: https://www.webforum.nu/p/870800

## #3 — niko, 2002-12-01T10:02Z

Det enkla svaret är naturligtvis att det alltid är bättre att köra **en** fråga än **tolv** frågor. 

Liknelse: Om du vill ha tolv bananer. Går du ner till affären tolv ggr och köper en banan? Eller går du ner en gång och köper tolv bananer?

Hur mycket prestandavinsten sen är går inte att ge ett *exakt* svar på. Det beror på hur frågorna ser ut, overheaden som  varje fråga har, hur mycket trafik som genereras av varje fråga, hur optimerade drivisarna är osv .. I vissa fall är det tolv ggr bättre.. ibland mer .. ibland mindre ..

Däremot förstår jag inte hur det kan vara säkerhetsmässigt bättre att ställa tolv frågor? 

Om du ställer tolv frågor och tex den sjätte fallerar så är ju risken *större* att få en inkonsistent databas (iaf om du inte använder transaktioner). Fast du kanske använder ordet "säkerhet" i en annan betydelse?

Permalänk: https://www.webforum.nu/p/870810

## #4 — koltrasten, 2002-12-01T10:23Z

Säkerhetsmässigt:
Om jag skall använda mig av 1 SQL-sats måste jag lagra saker i URL:en (querystring). Och om någon som är lite kunnig ändrar lite i adressfältet och trycker Enter kommer mitt script förstöras...

Permalänk: https://www.webforum.nu/p/870816

## #5 — niko, 2002-12-01T12:03Z

OK! Jag trodde det handlade om 12 vs 1 fråga i samma kontext (ASP-sida). Men vad du menar är att spara undan och skicka med frågor mellan olika sidor? I så fall kanske det ibland är bättre att dela upp databasfrågorna helt enkelt för att undvika en onödig komplexitet. Det beror ju helt på sammanghanget.

När det gäller säkerheten så är det väl en helt annan fråga. Du ska inte använda querystrings som folk kan gissa eller ändra i. Finns många varianter: koda om strängarna, koda om och använd hidden fields/sessions, använd HTTPS.

Permalänk: https://www.webforum.nu/p/870889

## #6 — koltrasten, 2002-12-01T15:45Z

Jag kommer ha det i loopar på samma sida. Alltså förenklat:

```
' SQL-sträng med top 5
Do Until RecSet.EOF
     SQL = "blablabla WHERE ID=" & RecSet("idet")
     %><%=RecSet("Titel")%><%
Loop
```

Sedan har jag två sådana på sidan så det blir egentligen **2** vs. **12**

Är det dåligt?

Permalänk: https://www.webforum.nu/p/871077

## #7 — niko, 2002-12-01T19:57Z

> Är det dåligt?

Ingen aning. Det beror ju på vilka alternativen är. Eller egentligen vad "blablabla" står för.

Om det är en SELECT så kanske allt hade gått smidigare med en JOIN. Om det är en något annat (DELETE, UPDATE, INSERT) så kanske det finns något smartare beroende på vad det är du egentligen tänker göra. Fast det är inte säkert. MySQL har sina begränsningar.

Permalänk: https://www.webforum.nu/p/871240

## #8 — koltrasten, 2002-12-01T20:03Z

Jag löste det med sessionsvariabler och fick ner det till 2 SQL-frågor

Tack för hjälpen!  :bire

Permalänk: https://www.webforum.nu/p/871243

---

Tråden på webben: https://www.webforum.nu/amne/databaser-sql/60778-antalet-sql-satser-prestanda
