Hva er bedre med MSSQL contra MYSQL?

[deviant]

Dette er ikke stedet å mene, her må man vite... 100% sikkert

 

Akkurat denne biten er litt vanskelig. Det er store versjonsforskjeller, og den tekniske detaljdokumentasjonen står ofte ikke i forhold. Det som var riktig på Oracle 9.2.0.1 eller MySQL 4.0.27 er kanskje ikke riktig for Oracle 9.2.0.4 eller MySQL 4.0.29. Og da har jeg ikke kommet inn på hovedversjoner.

 

Alle operasjoner som innebærer lesing eller skriving til en rad vil medføre at en lock må settes. Husk at en lock ikke nødvendigivis betyr "lås slik at ingen andre kan lese". Ved lesing settes en shared lock.

*snip*

 

Stemmer, derfor referansen til blokkerende lås. Hvordan dette faktisk fungerer fysisk er avhengig av datamotor og isolasjonsnivå. Terminologien varierer også.

 

 

At InnoDB kun benytter row-level locking høres ut som noe som kan skape problemer ved store recodsets. Det må da sluke mye minne å plassere en million låser istedet for en table lock, selv om concurrency selvfølgelig blir høyere. *snip*

 

Her er det mulig jeg er for rask, og at det finnes andre muligheter - spesielt i nyere versjoner. Tidligere var saken at selv når man ba om en hel tabell ble det satt låser på hver enkelt rad. Beste eksempelet er kanskje

delete from TABLE where field like '%pattern%' \

.

Ettersom MySQL må låse radene på InnoDB nivå, før LIKE kan evalueres, resulterer dette i en lås på hver enkelt rad i hele tabellen. Det er mulig et delte låser (mener MySQL kaller dem SHARED MODE LOCK) kan gjøres på andre nivåer.

Endret 13. desember 2007 av deviant

[Frank2004]

At InnoDB kun benytter row-level locking høres ut som noe som kan skape problemer ved store recodsets. Det må da sluke mye minne å plassere en million låser istedet for en table lock, selv om concurrency selvfølgelig blir høyere.

Liker bedre SQL Server sin måte å gjøre det på, nemlig å eskalere locks til en table-lock når antall row/key/page locks overskrider en grenseverdi.

Sprettert vs. pil og bue

Endret 19. desember 2007 av Frank2004

[roac]

Det er derfor jeg lurer på om MySQL og PostgreSQL har løst problemet med høy offset på en effektiv måte, eller om en støter på samme problemene som ved bruk av ROW_NUMBER() OVER() på SQL Server.

 

Roac, her har du en god ide til neste artikkel på mssql.no. Finn ut hvordan dette håndtere i de nevnte DBMS.

Da er jeg så smått i gang, det vil si at jeg i det minste har kommet i gang med planleggingen. Jeg søker å gjøre en relativt grundig test, der alle serverene kjører under samme betingelser, som blir et uniprosessorsystem med 512MB minne med Windows Server 2003 som OS. De databaseserverene som jeg planlegger å gjøre testene på er:

• SQL Server 2005
  
• SQL Server 2008
  
• DB2 9
  
• DB2 9.5
  
• MySQL 5
  
• MySQL 6
  
• PostgreSQL 8
  
• Oracle 10g
  
• Oracle 11g
  

[kaffenils]

Da er jeg så smått i gang

 

Skal bli spennede å se resultatet.

[blackbrrd]

Hvis du skal teste postgres vær obs på at det er relativt stor forskjell på 8.0, 8.1, 8.2... De var stort sett ferdig med features til 7.4, før de begynnte på optimalisering for å få opp ytelsen. Har lest endel på 8.3 og den ser ut til å være nok et stort sprang i ytelse...

[siDDis]

Jepp, 8.3 har visstnok store forbetringer når det gjelder ytelse. At den er enda ute i beta betyr jo bare at den ikkje bør brukas til produksjons

[kaffenils]

Stemmer det at PostgreSQL kun kjører på 32bits plattformer? Litt skuffende hvis dette er tilfelle.

[siDDis]

Så lenge det gjelder Windows ja.

[blackbrrd]

Har kjørt 64bit postgres siden AMD kom med Opteron 246 - på linux vel og merke

[kaffenils]

Har kjørt 64bit postgres siden AMD kom med Opteron 246 - på linux vel og merke

 

Jepp, ser det nå.