{"id":20930,"date":"2026-08-23T15:05:18","date_gmt":"2026-08-23T13:05:18","guid":{"rendered":"https:\/\/webhosting.de\/mariadb-query-optimizer-intern-erklaert-sql-tuning-insight\/"},"modified":"2026-08-23T15:05:18","modified_gmt":"2026-08-23T13:05:18","slug":"en-inblick-i-hur-mariadbs-frageoptimerare-fungerar-insikter-om-sql-optimering","status":"publish","type":"post","link":"https:\/\/webhosting.de\/sv\/mariadb-query-optimizer-intern-erklaert-sql-tuning-insight\/","title":{"rendered":"MariaDB:s fr\u00e5geoptimerare f\u00f6rklarad inifr\u00e5n: grunder, strategier och praktisk till\u00e4mpning"},"content":{"rendered":"<p>Jag f\u00f6rklarar <strong>MariaDB-optimeraren<\/strong> Fr\u00e5n praktiken: hur han skapar planer, ber\u00e4knar kostnader och varf\u00f6r han ibland har fel. S\u00e5 h\u00e4r l\u00e4ser du SQL-exekveringsplanen p\u00e5 ett m\u00e5linriktat s\u00e4tt, anv\u00e4nder index p\u00e5 ett meningsfullt s\u00e4tt och styr optimeraren med fakta ist\u00e4llet f\u00f6r magk\u00e4nsla.<\/p>\n\n<h2>Centrala punkter<\/h2>\n\n<p>Till att b\u00f6rja med sammanfattar jag kort de viktigaste delarna, s\u00e5 att du l\u00e4ttare kan s\u00e4tta in de f\u00f6ljande avsnitten i sitt sammanhang och <strong>\u00d6versikt<\/strong> beh\u00e5ller.<\/p>\n<ul>\n  <li><strong>Faser<\/strong>: Parsning, f\u00f6rberedelse, optimering och utf\u00f6rande utg\u00f6r livscykeln f\u00f6r varje s\u00f6kning.<\/li>\n  <li><strong>Kostnadsmodell<\/strong>: Tidsbaserade v\u00e4rden i mikrosekunder styr indexval, genoms\u00f6kningar och sammanfogningsordning.<\/li>\n  <li><strong>Statistik<\/strong>: Kardinalitet och histogram avg\u00f6r hur selektiviteten uppskattas.<\/li>\n  <li><strong>\u00d6ppenhet<\/strong>: EXPLAIN, EXPLAIN ANALYZE och Optimizer Trace \u00f6ppnar den svarta l\u00e5dan.<\/li>\n  <li><strong>Tuning<\/strong>: Index, omskrivning av fr\u00e5gor, ANALYZE TABLE och kostnadsparametrar ger snabbare prestanda.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mariaDB-query-plans-9842.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>En fr\u00e5gas livscykel i MariaDB<\/h2>\n\n<p>Innan en plan utarbetas genomg\u00e5r en fr\u00e5ga fyra steg, som jag noggrant granskar i det dagliga arbetet f\u00f6r att <strong>Orsaker<\/strong> f\u00f6r att hitta orsaker till l\u00e5ngsamhet. Vid parsningen omvandlar MariaDB SQL till en intern struktur; h\u00e4r uppt\u00e4cks syntaxfel. Under f\u00f6rberedelsen kontrollerar motorn tabeller, kolumner och potentiella index samt utf\u00f6r enkla omformuleringar. D\u00e4refter f\u00f6ljer optimeringen, d\u00e4r m\u00f6jliga planer ber\u00e4knas och utv\u00e4rderas med hj\u00e4lp av en kostnadsmodell. Vid exekveringen genomf\u00f6r servern den valda planen steg f\u00f6r steg: l\u00e4sning, sammanfogning, filtrering, returnering.<\/p>\n\n<p>Jag delar upp analysfelen tydligt efter fas, eftersom diagnoserna d\u00e5 ger snabbare resultat och <strong>\u00c5tg\u00e4rder<\/strong> verka m\u00e5linriktat. Prestandaproblem har oftast sin grund i optimeringen: felaktiga uppskattningar, saknade index eller ogynnsamma ordningar f\u00f6r sammanfogningar. Parsningsfel \u00e4r triviala, men f\u00f6rberedelsefasen kan redan inneh\u00e5lla finesser som uppl\u00f6sning av vyer eller omformuleringar av underfr\u00e5gor. Under exekveringen blir ineffektiviteterna sedan uppenbara om man tidigare valt en fullst\u00e4ndig genoms\u00f6kning. D\u00e4rf\u00f6r inleder jag varje utredning med en strukturerad genomg\u00e5ng av alla fyra stegen.<\/p>\n\n<h2>Hur optimeraren fattar beslut internt<\/h2>\n\n<p>MariaDB arbetar kostnadsbaserat och utv\u00e4rderar alternativa l\u00f6sningar genom en <strong>Kostnadsfunktion<\/strong>. F\u00f6r varje variant ber\u00e4knar servern antalet l\u00e4sta rader, selektiviteten hos WHERE\/ON, \u00e5tkomsttyper som tabellskanning, indexskanning och intervallskanning samt tids\u00e5tg\u00e5ngen f\u00f6r enskilda operationer. Internt skiljer servern mellan join_preparation och join_optimization. I join_preparation utf\u00f6rs omskrivningar av fr\u00e5gor, f\u00f6renklingar av villkor, omformuleringar av underfr\u00e5gor och uppl\u00f6sningar av vyer. I join_optimization ber\u00e4knas join-ordningar, indexkandidater kontrolleras via ref_optimizer_key_uses, rader uppskattas via intervallskanningar och villkor tilldelas specifika tabeller s\u00e5 tidigt som m\u00f6jligt.<\/p>\n\n<p>Denna mekanism f\u00f6rklarar varf\u00f6r ett litet filter p\u00e5 fel st\u00e4lle kan orsaka dyra <strong>Konsekvenser<\/strong> har. Om \u201dattaching_conditions_to_tables\u201d sker sent drar planen med sig on\u00f6digt m\u00e5nga rader genom join-operationer. Om statistiken \u00e4r f\u00f6r\u00e5ldrad blir \u201drows_estimation\u201d och \u201dSelectivity\u201d felaktiga; optimeraren v\u00e4ljer d\u00e5 tillg\u00e5ngsv\u00e4gar som verkar f\u00f6rdelaktiga men som i sj\u00e4lva verket \u00e4r l\u00e5ngsamma. Det \u00e4r just dessa justeringsm\u00f6jligheter jag fokuserar p\u00e5: b\u00e4ttre statistik, tydligare predikat, v\u00e4lordnade sammansatta index. D\u00e4refter f\u00f6r\u00e4ndras valet av plan ofta m\u00e4rkbart.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/MariaDBQueryOptKonferenz1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Prismodell fr\u00e5n och med MariaDB 11.0<\/h2>\n\n<p>Aktuella versioner bed\u00f6mer arbetet inte l\u00e4ngre grovt utifr\u00e5n vikter, utan med <strong>mikrosekunder<\/strong> f\u00f6r specifika lagringsoperationer. Parametrar som optimizer_disk_read_cost, optimizer_disk_read_ratio och optimizer_where_cost g\u00f6r att modellen b\u00e4ttre \u00e5terspeglar verkliga k\u00f6rtider. P\u00e5 s\u00e5 s\u00e4tt j\u00e4mf\u00f6r optimeraren index-range-scan med fullst\u00e4ndig skanning utifr\u00e5n verkliga tidsantaganden. LAST_QUERY_COST visar den uppskattade totalkostnaden och st\u00e4mmer ofta betydligt b\u00e4ttre \u00f6verens med verkligheten \u00e4n tidigare. F\u00f6r dataintensiva system ger denna finare uppdelning omedelbara f\u00f6rdelar.<\/p>\n\n<p>Jag kalibrerar modellen noggrant n\u00e4r h\u00e5rdvaruegenskaper strider mot standardantagandena och d\u00e4rmed <strong>Planval<\/strong> f\u00f6rvr\u00e4nga. NVMe-SSD:er, distribuerat lagringsutrymme eller s\u00e4rskilda cacher kan m\u00e4rkbart p\u00e5verka diskf\u00f6rh\u00e5llandet och l\u00e4stiderna. Sm\u00e5 justeringar av optimizer_costs g\u00f6r att MariaDB prioriterar l\u00e4mpliga s\u00f6kv\u00e4gar. Jag dokumenterar varje \u00e4ndring och kontrollerar d\u00e4refter EXPLAIN ANALYZE f\u00f6r att m\u00e4ta effekten. Utan m\u00e4tningar f\u00f6rblir optimeringen ett lotteri.<\/p>\n\n<h2>Selektivitet, statistik och histogram<\/h2>\n\n<p>Bra uppskattningar b\u00f6rjar med noggranna <strong>kardinalitet<\/strong> och tillf\u00f6rlitlig selektivitet. MariaDB f\u00f6r statistik \u00f6ver olika v\u00e4rden per kolumn och kan valfritt anv\u00e4nda histogram f\u00f6r f\u00f6rdelningar. S\u00e4rskilt oj\u00e4mnt f\u00f6rdelade data \u2013 hotspots, Zipf-f\u00f6rdelningar, s\u00e4songsm\u00f6nster \u2013 drar nytta av histogram. Efter stora data\u00e4ndringar k\u00f6r jag ANALYZE TABLE s\u00e5 att optimeringen \u00e5terigen baseras p\u00e5 aktuella fakta. Den som gl\u00f6mmer detta riskerar fullskanningar som objektivt sett \u00e4r felaktiga.<\/p>\n\n<p>Jag planerar att k\u00f6ra ANALYZE som ett \u00e5terkommande jobb, anpassat efter <strong>F\u00f6r\u00e4ndringar<\/strong> i datavolym och p\u00e5 kritiska tabeller. Vid kraftigt skeva kolumnf\u00f6rdelningar hj\u00e4lper histogram till att p\u00e5 ett realistiskt s\u00e4tt f\u00e5nga selektiviteten hos enstaka v\u00e4rden. Detta minskar risken f\u00f6r felbed\u00f6mningar vid intervalls\u00f6kningar och sammanslagningsstrategier. I kombination med l\u00e4mpliga sammansatta index f\u00f6rb\u00e4ttras tr\u00e4ffnoggrannheten avsev\u00e4rt. Resultat: kortare k\u00f6rtider och mindre I\/O.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mariadb-query-optimizer-guide-4729.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>EXPLAIN och l\u00e4sa exekveringsplaner<\/h2>\n\n<p>F\u00f6r att synligg\u00f6ra beslut anv\u00e4nder jag EXPLAIN, EXPLAIN EXTENDED och <strong>FORMAT=JSON<\/strong>. De klassiska kolumnerna ger en snabb \u00f6versikt: id, select_type, table, type, possible_keys, key, key_len, ref, rows och eventuellt filtered. Ett type=ALL indikerar en fullst\u00e4ndig genoms\u00f6kning, vilket s\u00e4llan \u00e4r \u00f6nskv\u00e4rt. FORMAT=JSON visar i detalj hur villkor har flyttats och vilka s\u00f6kv\u00e4gar optimeraren har utv\u00e4rderat. I samband med webbhotell rekommenderar jag guiden till <a href=\"https:\/\/webhosting.de\/sv\/exekveringsplaner-foer-databasfragor-hostingoptimering-prestandainsikter\/\">K\u00f6rningsplaner inom webbhotell<\/a>, f\u00f6r att koppla samman planeringsinformation med effekter p\u00e5 infrastrukturen.<\/p>\n\n<p>F\u00f6r att snabbt kunna tolka resultaten anv\u00e4nder jag en liten tabell som kortfattat sammanst\u00e4ller typiska v\u00e4rden och d\u00e4rmed <strong>Felaktiga tolkningar<\/strong> f\u00f6rhindras.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>EXPLAIN-f\u00e4lt<\/th>\n      <th>Typiskt v\u00e4rde<\/th>\n      <th>Betydelse i praktiken<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>typ<\/td>\n      <td>ALL, range, ref, eq_ref, const<\/td>\n      <td>Ju l\u00e4ngre till h\u00f6ger, desto mer selektivt; ALL indikerar fullskanning.<\/td>\n    <\/tr>\n    <tr>\n      <td>possible_keys<\/td>\n      <td>Indexlista<\/td>\n      <td>Index som teoretiskt sett passar; om det saknas kandidater h\u00e4r, saknas det struktur.<\/td>\n    <\/tr>\n    <tr>\n      <td>nyckel<\/td>\n      <td>Indexnamn<\/td>\n      <td>Index som faktiskt anv\u00e4nds; tomt f\u00e4lt inneb\u00e4r att indexet inte anv\u00e4nds.<\/td>\n    <\/tr>\n    <tr>\n      <td>rader<\/td>\n      <td>Antal<\/td>\n      <td>Uppskattat antal l\u00e4sta rader; avviker kraftigt fr\u00e5n verkligheten = d\u00e5lig statistik.<\/td>\n    <\/tr>\n    <tr>\n      <td>filtrerad<\/td>\n      <td>Procent<\/td>\n      <td>Hur mycket som sl\u00e4pps igenom efter filtret; en l\u00e5g niv\u00e5 \u00e4r ofta bra.<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Varf\u00f6r optimeringsverktyget ibland har fel<\/h2>\n\n<p>Ingen kostnadsmodell passar alla situationer, d\u00e4rf\u00f6r justerar jag <strong>Misstag<\/strong> m\u00e5lmedvetet. F\u00f6r\u00e5ldrad statistik leder till felaktiga uppskattningar av rader och ol\u00e4mpliga sammanfogningsordningar. Felaktigt uppbyggda sammansatta index f\u00f6rhindrar indexanv\u00e4ndning vid filter med flera kolumner. Mycket invecklade underfr\u00e5gor f\u00f6rsv\u00e5rar effektiva omskrivningar och blockerar materialisering. Saknade eller missvisande filter tvingar motorn att flytta m\u00e5nga rader innan anv\u00e4ndbara predikat tr\u00e4der i kraft.<\/p>\n\n<p>Jag kontrollerar f\u00f6rst om fr\u00e5gest\u00e4llningen uppfyller <strong>Index<\/strong> som verkligen fungerar: v\u00e4nsterprefixregel, l\u00e4mplig sorteringsordning, undvikande av funktioner p\u00e5 kolumner i WHERE. D\u00e4refter tittar jag i EXPLAIN ANALYZE f\u00f6r att se om verkligheten st\u00f6der uppskattningen. Om inte, f\u00f6ljer ANALYZE TABLE och vid behov en omskrivning. F\u00f6rst i sista hand anv\u00e4nder jag FORCE INDEX eller hinting, eftersom det kan begr\u00e4nsa framtida optimeringar.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mariadboptimizer_2219.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Anv\u00e4nda Optimizer Trace p\u00e5 ett m\u00e5linriktat s\u00e4tt<\/h2>\n\n<p>Om EXPLAIN inte r\u00e4cker till aktiverar jag Optimizer Trace och f\u00f6ljer <strong>Beslut<\/strong> i JSON-loggen. D\u00e4r kan jag se vilka planer som har \u00f6verv\u00e4gts, f\u00f6rkastats eller godk\u00e4nts. Jag f\u00f6rst\u00e5r varf\u00f6r ett villkor tr\u00e4der i kraft f\u00f6r sent eller varf\u00f6r ett index inte kom med i urvalet. Loggen visar ocks\u00e5 hur villkoren har omordnats. Denna \u00f6versikt f\u00f6rdjupar f\u00f6rst\u00e5elsen och ger konkreta verktyg f\u00f6r n\u00e4sta optimering.<\/p>\n\n<p>Jag sparar relevanta delar av sp\u00e5rningen tillsammans med fr\u00e5gehash och <strong>Parametrar<\/strong>v\u00e4rdera. P\u00e5 s\u00e5 s\u00e4tt kan jag senare j\u00e4mf\u00f6ra vilken \u00e4ndring som gav vilken effekt. Dokumentationen f\u00f6r MariaDB Server och olika f\u00f6redrag inom ekosystemet beskriver f\u00e4lten ing\u00e5ende (k\u00e4lla: MariaDB Server-dokumentation om Query Optimizer och Optimizer Trace). Med det h\u00e4r verktyget hittar jag felaktiga antaganden snabbare \u00e4n med trial-and-error. Jag sparar framf\u00f6r allt tid vid komplexa sammanfogningar.<\/p>\n\n<h2>Praktisk guide: Databasoptimering steg f\u00f6r steg<\/h2>\n\n<p>Jag inleder varje optimering med en tydlig <strong>M\u00e4tning<\/strong>. Jag identifierar problem genom \u00f6vervakning och det <a href=\"https:\/\/webhosting.de\/sv\/mysql-langsam-query-log-hosting-hosting-analys-queryperf\/\">L\u00e5ngsam fr\u00e5gelogg<\/a>. D\u00e4refter j\u00e4mf\u00f6r jag EXPLAIN med EXPLAIN ANALYZE f\u00f6r att st\u00e4lla plan och verklighet mot varandra. Jag anpassar indexstrategin efter WHERE, JOIN och ORDER BY; sammansatta index riktar jag in mot de vanligaste \u00e5tkomstpunkterna. Jag anv\u00e4nder FORCE INDEX endast om optimeraren v\u00e4ljer fel kandidat trots korrekta statistikuppgifter.<\/p>\n\n<p>Varje steg innefattar sk\u00f6tsel av <strong>Statistik<\/strong>: ANALYZE TABLE p\u00e5 tabeller med h\u00f6g aktivitet, histogram f\u00f6r skeva f\u00f6rdelningar. Jag f\u00f6renklar on\u00f6diga underfr\u00e5gor, materialiserar delresultat vid behov och rensar bort gamla tillf\u00e4lliga l\u00f6sningar. Vid anv\u00e4ndning av specialh\u00e5rdvara kontrollerar jag optimizer_costs f\u00f6r att s\u00e4kerst\u00e4lla att mikrosekundmodellen st\u00e4mmer. Jag dokumenterar varje \u00e4ndring med f\u00f6re- och efterv\u00e4rden s\u00e5 att effekten f\u00f6rblir sp\u00e5rbar p\u00e5 l\u00e5ng sikt.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mariadb_query_optimizer_8390.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Vanliga problem med optimeringsverktyg och l\u00f6sningar<\/h2>\n\n<p>Om EXPLAIN visar type=ALL trots att possible_keys \u00e4r ifyllt, tittar jag f\u00f6rst p\u00e5 <strong>Selektivitet<\/strong>. Ofta st\u00e4mmer inte kolumnordningen i det sammansatta indexet, eller s\u00e5 hindrar en funktion att indexet kan anv\u00e4ndas. D\u00e5 byter jag ordningen, tar bort st\u00f6rande funktioner eller delar upp predikat. Om join-ordningen \u00e4r felaktig kontrollerar jag om det g\u00e5r att filtrera tidigt, till exempel genom att flytta fram den mer selektiva tabellen. Subfr\u00e5gor omvandlar jag, d\u00e4r det \u00e4r l\u00e4mpligt, till join-operationer eller TEMPORARY-tabeller.<\/p>\n\n<p>Jag k\u00e4nner igen felaktiga beslut \u00e4ven n\u00e4r de avviker kraftigt fr\u00e5n <strong>rader<\/strong> mellan plan och verklighet. D\u00e5 kan kommandot ANALYZE TABLE eller ett histogram f\u00f6r den ber\u00f6rda kolumnen vara till hj\u00e4lp. Om inte ens korrekta statistikv\u00e4rden leder till \u00f6nskat resultat \u00f6verv\u00e4ger jag att anv\u00e4nda explicita hintar. Innan dess s\u00e4kerst\u00e4ller jag kontrollm\u00e4tningar och m\u00e4tv\u00e4rden, s\u00e5 att senare versioner av optimeraren inte h\u00e4mmas av lagrade inst\u00e4llningar. Disciplin n\u00e4r det g\u00e4ller dokumentation l\u00f6nar sig h\u00e4r.<\/p>\n\n<h2>Webbhotellssammanhang och driftsaspekter<\/h2>\n\n<p>S\u00f6kningens kvalitet och infrastrukturen m\u00e5ste st\u00e4mma \u00f6verens, annars g\u00e5r applikationen till spillo <strong>Potentiell<\/strong>. Snabba SSD-enheter, konsekventa cacher och en ren konfiguration utg\u00f6r grunden f\u00f6r att optimeringsverktyget ska kunna fatta bra beslut. H\u00f6g trafik t\u00e5l inga fullst\u00e4ndiga genoms\u00f6kningar; n\u00e5gra f\u00e5 d\u00e5liga s\u00f6kfr\u00e5gor kan bromsa upp hela system. F\u00f6r MySQL\/MariaDB-milj\u00f6er i produktiv drift ger praktiska tips som <a href=\"https:\/\/webhosting.de\/sv\/mysql-optimizer-query-hosting-optimering-serverboost\/\">MySQL-optimeraren<\/a> Anv\u00e4ndbara tankest\u00e4llare om kombinationen av plan och plattform. Den som tar h\u00e4nsyn till denna niv\u00e5 kan f\u00f6rebygga flaskhalsar innan de eskalerar.<\/p>\n\n<p>Jag kopplar alltid plananalysen till nyckeltal f\u00f6r <strong>I\/O<\/strong>, latens och parallellitet. Om v\u00e4rdena inte st\u00e4mmer \u00f6verens med den antagna kostnadsmodellen kontrollerar jag parametrarna. D\u00e4refter tittar jag p\u00e5 buffertstorlekar, parallella arbetsbelastningar och f\u00f6rdelningen av hotsets. Med detta tillv\u00e4gag\u00e5ngss\u00e4tt lyckas jag driva s\u00f6kningar och resurser p\u00e5 ett harmoniskt s\u00e4tt och h\u00e5lla toppbelastningarna under kontroll.<\/p>\n\n<h2>Join- och \u00e5tkomstv\u00e4gar i praktiken<\/h2>\n\n<p>Jag reder ut m\u00e5nga missf\u00f6rst\u00e5nd genom att <strong>\u00c5tkomsttyper<\/strong> v\u00e4ger noggrant mot varandra. Ett <em>intervall<\/em>- eller <em>ref<\/em>-\u00c5tkomst fungerar n\u00e4stan alltid <em>ALL<\/em>. Vid logiska kopplingar p\u00e5 unika nycklar (<em>eq_ref<\/em>) \u00e4r planerna s\u00e4rskilt stabila. Jag kontrollerar dessutom om en <strong>T\u00e4ckningsindex<\/strong> som helt t\u00e4cker fr\u00e5gan: Om alla n\u00f6dv\u00e4ndiga kolumner finns i indexet sparar MariaDB kostsamma tabell\u00e5tkomster. <strong>Nedpressning i indexerat tillst\u00e5nd (ICP)<\/strong> hj\u00e4lper till att redan i indexet kontrollera ytterligare WHERE-villkor \u2013 detta minskar antalet returnerade rader och I\/O.<\/p>\n\n<p>Om <strong>Indexsammanslagning<\/strong> MariaDB kan kombinera flera index (sk\u00e4rningsm\u00e4ngd\/f\u00f6rening). Detta \u00e4r anv\u00e4ndbart vid OR-predikat eller flera selektiva villkor, men ofta l\u00e5ngsammare \u00e4n ett v\u00e4lvalt sammansatt index. Jag utv\u00e4rderar dessutom <strong>MRR<\/strong> (l\u00e4sning \u00f6ver flera intervall) och <strong>BKA<\/strong> (Batched Key Access). MRR sorterar prim\u00e4rnycklar som ska l\u00e4sas f\u00f6r att j\u00e4mna ut slumpm\u00e4ssig I\/O; BKA sammanf\u00f6r join-uppslag och ger st\u00f6rst vinst vid join-operationer utan \u00f6verlappning. I praktiken testar jag BKA\/MRR via optimizer_switch och kontrollerar med EXPLAIN ANALYZE om I\/O-m\u00f6nstren minskar. Om MariaDB d\u00e4remot anv\u00e4nder <strong>Block med inb\u00e4ddade slingor<\/strong> (BNL) l\u00f6nar det oftast att anv\u00e4nda en st\u00f6rre join-buffert (join_buffer_size) \u2013 eller en omskrivning som m\u00f6jligg\u00f6r riktiga index-joins.<\/p>\n\n<pre><code>-- Exempel: Sammansatt index f\u00f6r join + filter + sortering\nCREATE INDEX ix_orders_cust_status_created\n  ON orders (customer_id, status, created_at);\n\n-- Typisk \u00e5tkomst\nSELECT *\nFROM orders o\nJOIN customers c ON c.id = o.customer_id\nWHERE o.status = 'open' AND o.created_at &gt;= '2026-01-01'\nORDER BY o.created_at DESC\nLIMIT 50;\n<\/code><\/pre>\n\n<p>Med ovanst\u00e5ende index kan optimeraren v\u00e4lja den mest selektiva ordningen, utv\u00e4rdera filter tidigt och ofta utf\u00f6ra sorteringen utan ytterligare filsortering.<\/p>\n\n<h2>ORDER BY, GROUP BY, fil sortering och tillf\u00e4lliga tabeller<\/h2>\n\n<p>Sortering och sammanst\u00e4llning tar tid. Jag ser till att <strong>ORDER BY<\/strong> och <strong>GRUPPERA EFTER<\/strong> kan k\u00f6ras i indexordningen. Det fungerar om prefixet och riktningen st\u00e4mmer exakt. Annars tr\u00e4der en <strong>Filsortering<\/strong> med sorteringsbuffert (sort_buffer_size) och eventuellt en tillf\u00e4llig tabell. Om resultatm\u00e4ngden inneh\u00e5ller breda TEXT-\/BLOB-kolumner m\u00e4rks MariaDB snabbare <em>p\u00e5 disk<\/em> TEMP-tabeller (Aria). Jag f\u00f6rebygger detta genom att endast v\u00e4lja de kolumner som beh\u00f6vs, ladda stora f\u00e4lt f\u00f6rst i slutet eller anv\u00e4nda prefix med begr\u00e4nsad l\u00e4ngd.<\/p>\n\n<p>Vid aggregeringar anv\u00e4nder jag, d\u00e4r det \u00e4r m\u00f6jligt, <strong>Skanning av l\u00f6s index<\/strong> (t.ex. GROUP BY p\u00e5 den ledande indexdelen) och v\u00e4lj sammansatta index l\u00e4ngs grupperingen. N\u00e4r mellanresultaten blir stora skalar en materialisering med l\u00e4mpliga nycklar b\u00e4ttre \u00e4n en enda megasammanfogning. Jag m\u00e4ter regelbundet handlarmetriker och Created_tmp_*-r\u00e4knare f\u00f6r att uppt\u00e4cka hotspots i sortering och tempor\u00e4ra tabeller.<\/p>\n\n<h2>Underfr\u00e5gor, semi-join och materialisering<\/h2>\n\n<p>M\u00e5nga underfr\u00e5gor kan omformuleras p\u00e5 ett effektivt s\u00e4tt redan under f\u00f6rberedelsefasen. IN\/EXISTS-konstruktioner kan anv\u00e4ndas som <strong>Semi-join<\/strong> k\u00f6ras, med strategier som materialisering eller LooseScan. Jag kontrollerar om optimeraren \u00e4r en <strong>derived_merge<\/strong> kunde genomf\u00f6ra: Om en h\u00e4rledd tabell (eller en WITH-CTE) inf\u00f6rlivas i den yttre planen, blir dess index direkt tillg\u00e4ngliga. Om detta inte lyckas hamnar underfr\u00e5gan i en tillf\u00e4llig tabell \u2013 jag ger den d\u00e5, om m\u00f6jligt, en nyckel (t.ex. genom SELECT DISTINCT\/ORDER BY p\u00e5 nyckelkolumner), s\u00e5 att sammanfogningar inte hamnar i ingenmanland.<\/p>\n\n<pre><code>-- Exempel: EXISTS ist\u00e4llet f\u00f6r IN och en sammanfogningsbar h\u00e4rledd tabell\nSELECT o.id\nFROM orders o\nWHERE EXISTS (\n  SELECT 1 FROM payments p\n  WHERE p.order_id = o.id AND p.state = 'captured'\n);\n\n-- H\u00e4rledning med entydiga nycklar\nWITH paid_orders AS (\n  SELECT DISTINCT order_id\n  FROM payments\n  WHERE state = 'captured'\n)\nSELECT o.*\nFROM orders o\nJOIN paid_orders po ON po.order_id = o.id;\n<\/code><\/pre>\n\n<p>Jag kontrollerar med EXPLAIN FORMAT=JSON om <strong>materialiserad<\/strong> eller . <strong>beroende underfr\u00e5ga<\/strong> valdes och om det finns villkor (<strong>villkorsnedskjutning<\/strong>) vidta \u00e5tg\u00e4rder i god tid.<\/p>\n\n<h2>Partitionering och besk\u00e4rning<\/h2>\n\n<p>Partitionering ers\u00e4tter inte index, men kan <strong>Datam\u00e4ngd per \u00e5tkomst<\/strong> minska drastiskt. Optimizern utf\u00f6r endast en korrekt besk\u00e4rning om predikatet uppfyller <strong>Partitionsnyckel<\/strong> tr\u00e4ffar entydigt och inte d\u00f6ljs av funktioner. Jag undviker d\u00e4rf\u00f6r uttryck som DATE(created_at) i WHERE-satsen f\u00f6r partitionerade tabeller och arbetar ist\u00e4llet med intervallgr\u00e4nser. EXPLAIN visar vilka partitioner som l\u00e4ses; breda intervall tyder p\u00e5 d\u00e5lig pruning.<\/p>\n\n<p>F\u00f6r m\u00e5nga sm\u00e5 partitioner \u00f6kar planeringsb\u00f6rdan. Jag v\u00e4ljer d\u00e4rf\u00f6r en l\u00e4mplig granularitet (t.ex. m\u00e5nadsvis ist\u00e4llet f\u00f6r dagligen), h\u00e5ller statistiken per partition uppdaterad (ANALYZE PARTITION) och kontrollerar om viktiga index finns lokalt i partitionerna. Vid migreringsprojekt tar jag h\u00e4nsyn till p\u00e5verkan p\u00e5 replikering och s\u00e4kerhetskopiering \u2013 b\u00e5da dessa faktorer p\u00e5verkar hur aggressivt jag partitionerar.<\/p>\n\n<h2>Sargability och omskrivningsm\u00f6nster<\/h2>\n\n<p>Den enklaste metoden \u00e4r fortfarande <strong>Sargability<\/strong> \u2013 Villkor som g\u00f6r det m\u00f6jligt att anv\u00e4nda index. Jag undviker funktioner p\u00e5 kolumner i WHERE-satsen, reducerar konstanterna till kolumnniv\u00e5 och delar upp OR-villkor vid behov i <strong>UNION ALL<\/strong>. F\u00f6r LIKE-s\u00f6kningar utan inledande ankare (\"%foo\") \u00e4r ett BTREE-index inte l\u00e4mpligt; h\u00e4r planerar jag att anv\u00e4nda fulltexts\u00f6kning eller en l\u00e4mplig s\u00f6ktj\u00e4nst. Vid ber\u00e4kningar anv\u00e4nder jag <strong>indexerade genererade kolumner<\/strong>, s\u00e5 att optimeraren kan \u00e5terfinna logiken i indexet.<\/p>\n\n<pre><code>-- Anti-m\u00f6nster: Funktion p\u00e5 kolumn\nWHERE DATE(created_at) = '2026-08-01'\n-- B\u00e4ttre: Intervall baserat p\u00e5 r\u00e5v\u00e4rde\nWHERE created_at &gt;= '2026-08-01' AND created_at &lt; &#039;2026-08-02&#039;\n\n-- Anti-m\u00f6nster: OR f\u00f6rhindrar indexering\nWHERE status = &#039;open&#039; OR customer_id = 42\n-- B\u00e4ttre: tv\u00e5 s\u00f6kningar med UNION ALL och varsitt eget index\n(SELECT ... WHERE status = &#039;open&#039;)\nUNION ALL\n(SELECT ... WHERE customer_id = 42&#039;);\n<\/code><\/pre>\n\n<p>N\u00e4r det g\u00e4ller sammansatta index anser jag att <strong>v\u00e4nsterprefixregeln<\/strong> F\u00f6lj detta strikt, ordna kolumnerna efter selektivitet och efter den sortering som kommer att beh\u00f6vas senare. Om jag beh\u00f6ver en ORDER BY i fallande ordning tar jag h\u00e4nsyn till detta i indexets uppbyggnad \u2013 p\u00e5 s\u00e5 s\u00e4tt slipper jag fil-sorteringen.<\/p>\n\n<h2>Optimeringsknapp och finjustering av kostnader<\/h2>\n\n<p>Innan jag b\u00f6rjar granska fr\u00e5gorna kontrollerar jag <strong>optimizer_switch<\/strong> och minnesbuffert. Funktioner som <em>mrr<\/em>, <em>batched_key_access<\/em>, <em>index_merge<\/em>, <em>semijoin<\/em>, <em>derived_merge<\/em> eller . <em>condition_pushdown_for_derived<\/em> kan anpassas per session. Jag aktiverar kandidater specifikt f\u00f6r en testsession, m\u00e4ter med EXPLAIN ANALYZE och \u00e5terst\u00e4ller om effekten uteblir. Join-v\u00e4gen drar nytta av tillr\u00e4cklig <strong>join_buffer_size<\/strong>; stora sorter av <strong>sortera_buffer_storlek<\/strong>. Samtidigt h\u00e5ller jag koll p\u00e5 buffertarna i f\u00f6rh\u00e5llande till samtidigheten, s\u00e5 att servern inte hamnar i swap-l\u00e4ge under parallell belastning.<\/p>\n\n<p>N\u00e4r det g\u00e4ller kostnaderna justerar jag, om det beh\u00f6vs, de redan n\u00e4mnda <strong>optimeringskostnader<\/strong> i mikrosekunder. Min riktlinje: sm\u00e5, reversibla steg med dokumenterade m\u00e4tpunkter. Jag anv\u00e4nder <strong>LAST_QUERY_COST<\/strong> f\u00f6r att kontrollera rimligheten och upprepa m\u00e4tningarna med realistiska parameterv\u00e4rden, eftersom planer i h\u00f6g grad kan bero p\u00e5 konkreta v\u00e4rden.<\/p>\n\n<h2>Planstabilitet, regressioner och teamets arbetsfl\u00f6de<\/h2>\n\n<p>\u00c4ven en bra plan kan p\u00e5verkas av datam\u00e4ngdens \u00f6kning eller versionsbyten <strong>tippa<\/strong>. D\u00e4rf\u00f6r samlar jag in information om planeringen: query-hashar, EXPLAIN-JSON, utdrag ur optimeringssp\u00e5rningen och k\u00f6rtider f\u00f6r EXPLAIN ANALYZE. \u00c4ndringar av index och omskrivningar sker hos mig som pull-f\u00f6rfr\u00e5gningar med f\u00f6re- och efterdokumentation. I CI\/CD-milj\u00f6er testar jag kritiska fr\u00e5gor automatiskt mot representativa datast\u00e4llningar. P\u00e5 s\u00e5 s\u00e4tt uppt\u00e4cker jag <strong>Regressionsplaner<\/strong> tidigt.<\/p>\n\n<p>I k\u00e4nsliga fall anser jag att <strong>Tips<\/strong> (FORCE INDEX, STRAIGHT_JOIN, optimizer_switch per fr\u00e5ga) finns som sista utv\u00e4g, men anv\u00e4nd dem sparsamt och med en tidsbegr\u00e4nsning. Det \u00e4r b\u00e4ttre att \u00e5tg\u00e4rda orsakerna \u2013 statistik, index, formulering. I team ser en l\u00e4ttviktig v\u00e4gledning f\u00f6r skalbarhet, indexdesign och m\u00e4tdisciplin till att nya funktioner inte obem\u00e4rkt inf\u00f6r prestandaproblem.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mariadb-query-optimizer-7832.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kort sammanfattning: Fr\u00e5n plan till resultat<\/h2>\n\n<p>Vem kan anv\u00e4nda <strong>Planera<\/strong> f\u00f6rst\u00e5r och styr prestandan. Faserna Parsing, Preparing, Optimizing och Executing visar var tid g\u00e5r f\u00f6rlorad. Den tidsbaserade kostnadsmodellen fr\u00e5n version 11.0 och v\u00e4lunderh\u00e5llna statistiska uppgifter och histogram g\u00f6r uppskattningarna tillf\u00f6rlitliga. EXPLAIN, EXPLAIN ANALYZE och Optimizer Trace ger insyn, vilket jag omvandlar till konkreta \u00e5tg\u00e4rder. Med en v\u00e4l genomt\u00e4nkt indexstrategi, tydlig utformning av fr\u00e5gor och l\u00e4mplig infrastruktur levererar MariaDB-fr\u00e5gor genomg\u00e5ende snabba svar.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e4r dig hur MariaDB:s fr\u00e5geoptimerare fungerar internt, hur du analyserar SQL-exekveringsplanen med EXPLAIN och hur du genomf\u00f6r praktisk databasoptimering \u2013 inklusive tips f\u00f6r h\u00f6gpresterande webbapplikationer.<\/p>","protected":false},"author":1,"featured_media":20923,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-20930","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"144","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"MariaDB Optimizer","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20923","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/20930","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/comments?post=20930"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/20930\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media\/20923"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media?parent=20930"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/categories?post=20930"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/tags?post=20930"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}