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

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 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 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

Tabel	Indhold	Værd at vide
wp_posts	Sider, indlæg, produkter, menupunkter og revisioner	Revisioner kan fylde mere end selve indholdet
wp_postmeta	Ekstradata til indlæg: priser, lager, felter fra plugins	Tabellen, der typisk vokser mest
wp_options	Sitets indstillinger og transients	Autoloadede rækker indlæses ved hver sidevisning
wp_users / wp_usermeta	Brugere og deres indstillinger	Kunder i WooCommerce er også brugere
wp_comments	Kommentarer og produktanmeldelser	Spam 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.

Kig ind i databasen uden at ødelægge noget

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.

Læs også

• Ordbog: Hosting-ordbogen
• Databasetabel beskadiget: „marked as crashed“ – reparér sikkert
• Find langsomme databasekald med Query Monitor
• Databaseoprydning i LiteSpeed Cache: revisioner, transients og autoload
• Fejl ved oprettelse af databaseforbindelse i WordPress
• Hvad er WordPress?
• WordPress hosting hos Hostious – NVMe-lagring og daglig backup med selvbetjent gendannelse

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.