Webbhotell med MySQL-databas

MySQL och MariaDB driver nästan allt du kör

Nästan alla dynamiska webbplatser bygger på en relationsdatabas, och för delad hosting på svenska webbhotell är det i praktiken alltid MySQL eller dess nära släkting MariaDB som gäller. WordPress, WooCommerce, Joomla, PrestaShop, de flesta ramverk och ett otal egenutvecklade applikationer förutsätter att ett av dessa databashanteringssystem finns på plats. Väljer du ett webbhotell utan MySQL-stöd stänger du ute merparten av det CMS-ekosystem som existerar.

Det som sällan är lika tydligt på prissidan är hur databasen är konfigurerad. Antal tillåtna databaser, maximala anslutningar, gränser för databasstorleken och huruvida du kan ansluta med externa verktyg är detaljer som skiljer webbhotell åt i praktiken, inte bara i marknadsföringen.

MySQL eller MariaDB, spelar det roll?

Förväxlingen är begriplig. MariaDB skapades 2009 av MySQL:s ursprungliga grundare som en community-driven fork när Oracle förvärvade MySQL, och de två systemen har under lång tid haft nästan identisk syntax och API. De flesta program som fungerar med MySQL fungerar utan ändringar mot MariaDB.

I praktiken kör en stor andel svenska webbhotell MariaDB på sina delade servrar. Det är ett aktivt, välunderhållet projekt med tätare releasecykel, och på matchade hårdvara presterar det ofta marginellt bättre för läs-tunga arbetsbelastningar som en vanlig WordPress-sajt. MySQL 8.0 och 8.4 har å sin sida ett antal förbättringar i query-optimizern och stöd för window functions som MariaDB hanterar lite annorlunda. För de allra flesta användare på delad hosting spelar skillnaden ingen avgörande roll. Det är värt att känna till distinktionen, men det ska inte vara ett avgörande val när du jämför webbhotell.

En praktisk sak att märka: MySQL 8.0 tog bort den inbyggda query cache som fanns i 5.x-versionerna. Det var en funktion som cacha resultaten av identiska SELECT-frågor, och som många gamla optimeringsguider förutsatte. Om du stöter på råd om att aktivera query_cache_size kan du avfärda dem, de gäller inte längre för moderna installationer. Objektcache via Redis är det korrekta sättet att hantera det på applikationsnivå idag.

Varför max_connections är den dolda flaskhalsen

Moderna PHP-applikationer som WordPress öppnar en ny databasanslutning för varje sidanrop, och stänger den när skriptet är klart. På en lugn sajt med ett fåtal besökare per minut är det oproblematiskt. Men vid en trafiktopps, ett nyhetsbrev som skickas ut, en länk som sprids på sociala medier, händer något annat.

Om 30 simultana besökare träffar sajten på en sekund försöker 30 PHP-processer öppna 30 databasanslutningar samtidigt. Har webbhotellet begränsat kontot till 15 parallella anslutningar misslyckas hälften av förfrågningarna med ett "Too many connections"-felmeddelande. Det syns inte som ett PHP-fel eller en kraschad server. Besökaren ser en vit sida eller ett generiskt serverfel, och du ser ingenting i webbhotellspanelen förrän du gräver i loggarna.

Lösningen är inte nödvändigtvis att uppgradera till ett dyrare paket. En persistent anslutningspool via Redis eller aktiverat ProxySQL (om webbhotellet stöder det) kan minska antalet faktiska anslutningar dramatiskt utan att du behöver byta plan. Det är dock en konfigurationsfråga som de flesta delade webbhotell inte exponerar för slutanvändaren. Praktiskt innebär det att du bör testa hur sajten beter sig under belastning, inte bara i lugnt läge, innan du väljer ett paket för en sajt som förväntas ta emot trafiktoppar.

phpMyAdmin, Adminer och att ansluta utifrån

De flesta webbhotell med cPanel levererar phpMyAdmin, ett välbeprövat webbgränssnitt för att bläddra i tabeller, köra SQL-frågor och exportera databaser till .sql-filer. Det är stabilt och brett dokumenterat, om än lite tungdriven för stora databaser. Adminer är ett lättare alternativ som är populärt hos webbhotell med DirectAdmin eller egna kontrollpaneler.

Fjärranslutning till databasen, det vill säga att ansluta från din lokala dator med ett klientverktyg som TablePlus, DBeaver eller MySQL Workbench, är praktiskt när du ska importera stora datamängder, jämföra tabeller eller felsöka en komplex migrationsfråga. De flesta webbhotell blockerar externa anslutningar som standard och kräver att du vitlistar en specifik IP-adress i kontrollpanelen. Det är en rimlig säkerhetsåtgärd, men det betyder att du bör kontrollera att det överhuvudtaget är möjligt hos det webbhotell du väljer om det är ett arbetsflöde du behöver.

Kör du en WooCommerce-butik med hundratals tusen orderposter, eller en sajt som bygger om kategorisidor med komplexa JOIN-frågor, kan ett externt verktyg med möjlighet att köra EXPLAIN på långsamma frågor spara timmar av felsökningstid. Det är den typen av möjlighet som särskiljer ett mer öppet webbhotell från ett mer låst paket.

Databasversion och supportstatus: frågan vi glömde ställa

Vi lär oss tidigt att fråga efter PHP-versionen när vi väljer webbhotell. PHP-sidan här på sajten ägnar ett helt avsnitt åt EOL-datum och säkerhetsfönster. Men databasen frågar nästan ingen om. Det är en asymmetri värd att uppmärksamma, för 2026 är året då båda de versioner som svenska webbhotell ofta vilar på gick ur community-support.

MySQL 8.0 täcks sedan våren 2026 av Oracles Sustaining Support, en nivå som inte längre levererar nya säkerhetspatchar utan bara bästa möjliga stöd för redan kända fel. Oracle rekommenderar uppgradering till MySQL 8.4 LTS eller 9.7 LTS. MariaDB 10.6 nådde community-EOL den 6 juli 2026, med orden att inga fler bugg- eller säkerhetsrättningar kommer från projektet. Klara besked från båda håll.

Det här är en annan axel än prestanda. Versionen i sig spelar liten roll för hur snabbt databasen svarar, det avgör resursisoleringen och antalet anslutningar som vi gått igenom ovan. Supportstatus handlar i stället om säkerhet och underhåll. Det är skillnaden mellan att veta att plattformen aktivt underhålls och att hoppas att inget allvarligt dyker upp.

EOL är inte detsamma som oskyddad

Här är nyansen som de flesta internationella "uppgradera nu"-artiklar hoppar över. Community-EOL betyder inte automatiskt att databasen slutar få säkerhetsrättningar. Rätt fråga är inte om ditt webbhotell kör en gammal version, utan varifrån säkerhetspatcharna till den versionen kommer.

Webbhotell som använder CloudLinux som serveroperativsystem har tillgång till Endless Lifecycle Support (ELS), som backportar säkerhetsrättningar efter att community-stödet upphört. MariaDB 10.6 ingår i det. En sajt som kör 10.6 på ett CloudLinux-baserat webbhotell kan alltså vara fullt patchad för kända sårbarheter trots att MariaDB-projektet självt inte längre underhåller grenen. Det är en reell skillnad som inte syns i versionsnumret.

Att köra en community-EOL-version är därför inte automatiskt ett tecken på slarv hos webbhotellet. Patchar kan komma via CloudLinux ELS, en uppgradering kan vara planerad, eller så backportar leverantören egna rättningar. Det du behöver veta är vilket av alternativen som gäller för just din server.

Livscykel i korthet: vad som stöds och hur länge

Tabellen sammanfattar läget för de versioner du troligast möter. Notera att uppgraderingsmålen har sina egna livslängder. Väljer du MySQL 9.7 LTS sitter du tryggt till 2034, medan MariaDB 11.4 LTS håller till 2029.

Källor: endoflife.date/mysql och endoflife.date/mariadb. Det längst hållbara enskilda valet är MySQL 9.7 LTS med stöd till 2034. Men för en typisk WordPress-sajt på ett delat webbhotell är det leverantören som väljer version, inte du. Det är själva argumentet för att fråga.

Tre steg för att bedöma din situation

Du behöver inte byta webbhotell för att göra kontrollen. Tre steg räcker.

1. Kör SELECT VERSION(); i phpMyAdmin eller Adminer. Det ger dig det exakta versionsnumret, inte marknadsföringstexten på prissidan.
2. Jämför mot tabellen ovan. Är du på MySQL 8.0 eller MariaDB 10.6 är community-stödet borta. Det är ingen kris, men det är utgångspunkten för nästa steg.
3. Fråga webbhotellet. En rimlig och konkret fråga: kör ni CloudLinux med ELS för MariaDB 10.6, eller planerar ni en uppgradering, och i så fall när? Ett webbhotell som inte kan svara har troligen inte tänkt igenom sin patch-strategi.

Ett exempel på en leverantör som redan kört vidare är Oderland, som använder MariaDB 11.4, en modern LTS-gren, och CloudLinux med CageFS i sin webbhotellsmiljö. Det är ett mönster att titta efter när du jämför, inte versionen som ett prestandaargument, utan som ett tecken på om leverantören håller sin infrastruktur ajour.