Dansk hosting fra Aalborg
Servere i Europa
24/7/365 dansk support
support@hostious.io
Hosting-ordbogen 11 min. læsning Opdateret 18. oktober 2026

Hvad er en MySQL-database? Dit indholds egentlige hjem

Hvad er en MySQL-database, og hvad er en database overhovedet? Tabeller, rækker og kolonner med WordPress som eksempel – og én sidevisning trin for trin.

Hvad er en MySQL-database? Dit indholds egentlige hjem

Kort svar: MySQL (eller den kompatible MariaDB) er databasen bag dit WordPress-site: alt dit INDHOLD – sider, indlæg, produkter, ordrer, brugere og indstillinger – ligger i dens tabeller, mens filerne på serveren kun rummer kode, temaer og uploads. Hver sidevisning, der ikke reddes af cache, er en stribe databaseforespørgsler. Deraf de to praktiske sandheder: en backup uden databasen er ingen backup – og en langsom database gør hele sitet langsomt.

Fagligt gennemgået: 2. oktober 2026

Kontrolgrundlag: Tabelnavne, kommandoer og konfigurationseksempler er kontrolleret mod en standardinstallation af WordPress 18. oktober 2026; Hostious’ planer og egenskaber er aflæst på pengesiderne samme dag.

Hvad er en database – og hvad er en MySQL-database helt konkret? Databasen er den del af dit site, du sjældent ser, men oftest er afhængig af. Den er der, hver gang en side bygges, en ordre gemmes eller en indstilling ændres. Her får du først det grundlæggende – tabeller, rækker og kolonner – og derefter skellet mellem filer og database, de tabeller, du bør kende, og de håndgreb, der holder databasen hurtig og sikker, uden at du behøver at være udvikler.

Hvad er en database – helt grundlæggende?

En database er et system, der gemmer data i tabeller og kan finde dem igen hurtigt. Hver tabel har kolonner (hvad der gemmes) og rækker (de enkelte poster). En MySQL-database er en database, der styres af programmet MySQL – en databaseserver, der tager imod forespørgsler på sproget SQL, slår op i tabellerne og sender svaret tilbage. WordPress er skrevet til MySQL og den kompatible MariaDB; dit site kan ikke starte uden en af dem.

Sådan ser et lille udsnit af tabellen wp_posts ud på et almindeligt site:

IDpost_titlepost_typepost_status
12Om ospagepublish
48Fem tips til hurtigere WordPresspostpublish
310Sort t-shirt, str. Mproductpublish
311Sort t-shirt, str. M (kladde)productdraft

Kolonnen ID er nøglen: andre tabeller peger på den. Prisen på t-shirten står ikke i wp_posts, men i wp_postmeta som en række med post_id = 310, meta_key = _price og meta_value = 199. Det er det, “relationel” betyder: tabellerne hænger sammen gennem id’er, og databasen samler dem, når WordPress spørger.

Tre begreber, der ofte blandes sammen: databaseserveren er programmet (MySQL eller MariaDB), der kører på hostingen; databasen er dit sites samling af tabeller med sit eget navn, brugernavn og kodeord; tabellen er én liste i databasen. På et webhotel deler mange sites én databaseserver, men hvert site bør have sin egen database. Hos Hostious får hvert WordPress-site og hver WooCommerce-webshop egen database – se WooCommerce hosting, hvor det betyder mest, fordi kurv og checkout rammer databasen ved hvert klik.

Hvad ligger hvor?

Skellet er værd at kunne udenad, for det styrer både backup og flytning: filerne rummer WordPress-kernen, temaer, plugins og dine uploadede billeder – databasen rummer alt det, du har SKREVET og SOLGT: tekster, produkter, ordrer, kunder, kommentarer og hver eneste indstilling. Mister du filerne, kan kode geninstalleres og billeder ofte reddes; mister du databasen, er selve forretningens hukommelse væk. Derfor består en rigtig backup altid af begge dele – og en gendannelse af det rigtige samspil mellem dem.

Sådan finder WordPress sin database

Forbindelsen står i wp-config.php i sitets rodmappe. Fire konstanter og ét præfiks afgør, hvor WordPress henter sine data:

define( 'DB_NAME', 'databasens_navn' );
define( 'DB_USER', 'databasebruger' );
define( 'DB_PASSWORD', 'adgangskode' );
define( 'DB_HOST', 'localhost' );
$table_prefix = 'wp_';

Er bare én af dem forkert – typisk efter en flytning eller et skift af adgangskode – får du „Fejl ved oprettelse af databaseforbindelse“. Diagnosen står i guiden til databaseforbindelsesfejlen. Tabelpræfikset (her wp_) er grunden til, at flere sites kan dele én database; i resten af artiklen bruger vi standardpræfikset, men dit kan hedde noget andet.

Tabellerne, du bør kende

Oversigt over WordPress-databasens vigtigste tabeller
Diagnoseillustration: kernetabellerne i en WordPress-database og deres roller.
TabelIndholdVærd at vide
wp_postsSider, indlæg, produkter, menupunkter og revisionerRevisioner kan fylde mere end selve indholdet
wp_postmetaEkstradata til indlæg: priser, lager, felter fra pluginsTabellen, der typisk vokser mest
wp_optionsSitets indstillinger og transientsAutoloadede rækker indlæses ved hver sidevisning
wp_users / wp_usermetaBrugere og deres indstillingerKunder i WooCommerce er også brugere
wp_commentsKommentarer og produktanmeldelserSpam kan fylde, hvis den ikke slettes

WooCommerce tilføjer egne tabeller. Nyere shops gemmer ordrer i dedikerede ordretabeller (HPOS – High-Performance Order Storage), som har været standard for nye installationer siden WooCommerce 8.2, mens ældre shops kan have ordrerne liggende i wp_posts og wp_postmeta. Under WooCommerce → Indstillinger → Avanceret → Funktioner kan du se, hvilken lagring din shop bruger.

To hverdagskonsekvenser: oprydning i transients og revisioner er ægte vedligehold, og går en tabel i stykker („marked as crashed“), er der en kendt reparationsvej.

Hvad betyder det for dit site?

Tre håndgreb gør størst forskel:

  • Backup med database: tjek, at din backupløsning eksplicit tager databasen, og at du har prøvet en gendannelse, før du får brug for den.
  • Aflast med objektcache: Redis gemmer hyppige databasesvar i RAM og mærkes især i wp-admin og på dynamiske sider som kurv og konto.
  • Jagt de langsomme kald: Query Monitor viser, hvilket plugin der koster mest tid pr. sidevisning.

Hardwaren betyder også noget: en database laver mange små læsninger og skrivninger, og dem håndterer NVMe-lagring markant bedre end ældre diske. Det er en af grundene til, at WordPress hosting hos Hostious kører på NVMe.

Hvad sker der i databasen ved én sidevisning?

Når en besøgende åbner en side, der ikke ligger i cachen, går WordPress samme vej hver gang. Forløbet forklarer både, hvorfor autoload og tunge plugins kan mærkes, og hvorfor cache gør så stor forskel:

Fem trin i én sidevisning: den besøgende beder om en side, WordPress åbner databaseforbindelsen via wp-config.php, henter de autoloadede rækker fra wp_options, slår indlæg, meta og termer op og bygger siden, som derefter kan caches
Hvert trin er én eller flere forespørgsler til databasen. Sidecache springer hele kæden over; objektcache gør trin 3 og 4 billigere.
  1. Forespørgslen kommer ind. Webserveren starter PHP og WordPress.
  2. Forbindelsen åbnes. WordPress læser wp-config.php og logger ind på databasen. Fejler det, ser den besøgende “Fejl ved oprettelse af databaseforbindelse”.
  3. Indstillingerne hentes. Alle autoloadede rækker i wp_options læses i én forespørgsel – uanset om siden bruger dem.
  4. Indholdet slås op. Selve indlægget, dets meta, kategorier og tags, menuen, widgets og det, temaet og plugins beder om. På en simpel side er det ofte 20–50 forespørgsler; med mange plugins kan det blive over 100.
  5. Siden bygges og gemmes. HTML’en sendes til den besøgende, og med sidecache gemmes den, så næste besøgende får den uden at røre databasen.
LagHvad det sparerHvor det mærkes
Sidecache (fx LiteSpeed Cache)Hele kæden – ingen databasekald for cachede siderForside, artikler, produktsider
Objektcache (Redis)Gentagne opslag i trin 3 og 4 gemmes i RAMwp-admin, kurv, checkout, “min konto”
Hurtig lagring (NVMe)Tiden pr. forespørgsel, når databasen skal læse fra diskAlt, der ikke kan caches

Antallet af forespørgsler kan du se med Query Monitor (afsnittet nedenfor), og det er det tal, der afslører et plugin, der spørger databasen 300 gange for at vise en knap.

Kig ind i databasen uden at ødelægge noget

WP-CLI-opslag der viser de fem største tabeller i en WordPress-database – wp_postmeta og Action Scheduler-loggen fylder mest

Du behøver ikke være udvikler for at se, hvad der fylder. De fleste hostingkontrolpaneler har phpMyAdmin, hvor fanen „Struktur“ viser hver tabel med antal rækker og størrelse. Sortér på størrelse, og du har svaret på, hvorfor backuppen er blevet på 800 MB: typisk wp_postmeta, wp_options med gamle transients eller en logtabel fra et plugin, der er holdt op med at rydde op efter sig. Har du WP-CLI, giver disse kommandoer samme overblik i terminalen:

wp db size --tables
wp db query "SELECT table_name, ROUND((data_length + index_length)/1024/1024, 1) AS mb FROM information_schema.tables WHERE table_schema = DATABASE() ORDER BY mb DESC LIMIT 5;"

Reglen for at røre ved databasen er enkel: læs frit, skriv kun efter backup. En SELECT kan ikke ødelægge noget; en DELETE uden WHERE tømmer en tabel på et sekund. Eksportér databasen (phpMyAdmin → Eksportér eller wp db export), før du sletter så meget som én række.

Autoload: den skjulte vægt i wp_options

Rækker i wp_options, der er markeret til autoload, indlæses ved hver eneste sidevisning – også når de ikke bruges. Plugins, der er slettet, efterlader ofte autoloadede indstillinger, og over tid kan de veje så meget, at hver forespørgsel bliver tungere. Site Health advarer, når mængden af autoloadede data bliver stor. Med WP-CLI kan du se de tungeste rækker:

wp option list --autoload=on --fields=option_name,size_bytes --format=csv | sort -t, -k2 -nr | head -n 15

Kender du rækken fra et plugin, du har fjernet, kan den typisk slettes efter backup. Kender du den ikke, så lad den være og spørg din udvikler – nogle af de store rækker er helt legitime.

MySQL eller MariaDB – og hvorfor versionen betyder noget

MariaDB er en aflægger af MySQL, startet af nogle af de oprindelige MySQL-udviklere, efter at MySQL kom på Oracles hænder. WordPress kører på begge uden at kunne mærke forskel, og mange hosts vælger MariaDB, fordi den udvikles som open source. Det, der betyder noget, er versionen: WordPress anbefaler pr. oktober 2026 MySQL 8.0 eller nyere eller MariaDB 10.11 eller nyere sammen med PHP 8.3 eller nyere. Ældre versioner kan stadig køre WordPress, men har nået end of life og får ikke længere sikkerhedsrettelser. Under Værktøjer → Webstedets helbred → Info → Database står, hvad dit site kører på.

To indstillinger på databaseserveren mærkes direkte i WordPress: tegnsættet skal være utf8mb4, ellers går emojis og nogle specialtegn i stykker ved import; og InnoDB skal være tabeltypen – gamle MyISAM-tabeller låser hele tabellen ved skrivning og er en typisk grund til „marked as crashed“-fejl efter et nedbrud. Begge dele kan du se i phpMyAdmin, og begge kan konverteres, hvis de står forkert – men tag en backup først.

Databasen ved flytning og domæneskift

Ved en flytning skal databasen eksporteres og importeres sammen med filerne. Skifter domænet samtidig, skal de gamle adresser erstattes – og her ligger den klassiske fejl: mange plugins gemmer data i serialiseret form, hvor længden på hver tekst står gemt sammen med teksten. En rå søg/erstat i SQL-filen ændrer teksten, men ikke længden, og så går indstillinger og widgets tabt. Brug derfor et værktøj, der forstår serialiserede data:

wp search-replace 'https://gammeltdomaene.dk' 'https://nytdomaene.dk' --all-tables --dry-run

Kør først med --dry-run, så du ser, hvor mange forekomster der ændres, og fjern det, når tallet ser rigtigt ud. Hele forløbet står i guiden Flyt WordPress til nyt domæne uden SEO-tab.

Tre vaner, der holder databasen sund

  • Begræns revisioner. Hver gemning af en side laver en kopi i wp_posts. define( 'WP_POST_REVISIONS', 5 ); i wp-config.php holder det på fem pr. side.
  • Ryd transients månedligt. Udløbne transients kan blive liggende. wp transient delete --expired eller et vedligeholdelsesplugin klarer det.
  • Slet plugins rigtigt. Deaktivering efterlader tabellerne. Brug pluginnets egen „slet data ved afinstallation“, hvis den findes, og tjek bagefter i phpMyAdmin for tabeller med pluginnets præfiks.

Vil du have en database, der er sat op til WordPress fra start? Hos Hostious kører WordPress hosting på NVMe og AMD EPYC med egen database, understøttelse af Redis object cache og daglig backup af både filer og database – fra 39 kr./md. ekskl. moms. Driver du webshop, giver WooCommerce hosting fra 59 kr./md. webshoppen egen database og Redis, fordi kurv og checkout ikke kan caches. Er sitet allerede langsomt, finder vi flaskehalsene med hastighedsoptimering af WordPress.

Læs også

Ofte stillede spørgsmål om MySQL

Er MySQL og MariaDB det samme?

I WordPress-sammenhæng i praksis ja: MariaDB er en kompatibel videreførelse af MySQL, og WordPress kører ens på begge. Det vigtige er en nyere version (MySQL 8.0 eller MariaDB 10.11 og nyere), tegnsættet utf8mb4 og InnoDB som tabeltype.

Skal jeg selv ind i databasen?

Sjældent – og aldrig uden frisk backup først. De legitime ærinder er fejlfinding (reparation af tabeller, søg/erstat ved flytning) og oprydning. Alt andet klarer WordPress og dine plugins selv.

Hvorfor vokser min database, når jeg ikke tilføjer indhold?

Revisioner, transients, logs og plugin-spor samler sig over tid – især i wp_options og wp_postmeta. Planlæg en årlig oprydning; mindre database betyder hurtigere forespørgsler og mindre backup.

Kan jeg slette ting i databasen for at gøre sitet hurtigere?

Ja, men kun efter en eksport. Udløbne transients, gamle revisioner og tabeller fra slettede plugins kan fjernes uden tab. Rør aldrig wp_posts, wp_postmeta eller ordretabeller i hånden uden at vide præcis, hvad rækkerne er.

Hvorfor virker sitet ikke, efter jeg har importeret databasen et nyt sted?

Typisk fordi wp-config.php stadig peger på den gamle database, bruger eller adgangskode, eller fordi tabelpræfikset ikke passer til de importerede tabeller. Skifter domænet samtidig, skal adresserne også opdateres med et værktøj, der håndterer serialiserede data.

Hvad er forskellen på en database og en databaseserver?

Databaseserveren er programmet – MySQL eller MariaDB – der kører på hostingen og kan rumme mange databaser. Databasen er dit sites egen samling af tabeller med eget navn, brugernavn og kodeord. I wp-config.php peger DB_HOST på serveren og DB_NAME på databasen.

Hvem tilbyder WordPress hosting med egen database og Redis?

Hostious giver hvert WordPress-site og hver WooCommerce-webshop egen database og understøttelse af Redis object cache på NVMe-lagring – WordPress hosting fra 39 kr./md. og WooCommerce hosting fra 59 kr./md. ekskl. moms, begge med daglig backup af filer og database, gratis SSL og dansk support døgnet rundt på servere i Europa.

Skrevet af Marc, stifter af Hostious

Jeg hedder Marc og har stiftet Hostious. Vi hoster WordPress-hjemmesider og WooCommerce-webshops for danske virksomheder – drevet fra Aalborg-området med servere i Europa – og jeg skriver guiderne her ud fra det, vi ser i driften hver dag.

Udgivet 31. august 2026Opdateret 18. oktober 2026Fagligt gennemgået 2. oktober 2026