Ga naar de hoofdinhoud
{}

SQL-expertise voor MySQL, MariaDB & SQL Server

SQL- en MySQL-expert voor query-optimalisatie en migraties.

Trage SQL-query’s, rapporten, applicaties of een geplande migratie? Codegenie onderzoekt queryplannen, indexen en dataconsistentie in MySQL, MariaDB en Microsoft SQL Server.

Een traag systeem of een geplande migratie?

Begin met de situatie die je wilt laten onderzoeken. Kies bij contact de categorie SQL-queryanalyse of databaseprobleem en vermeld of het om queryproblemen of een migratie gaat.

Trage queries of databaseproblemen

Om te beginnen: beschrijf welke handeling vastloopt, wanneer dat gebeurt en welke database en versie je gebruikt. Deel eventueel een geanonimiseerde query, tabelstructuur of uitvoeringsplan waaruit gevoelige waarden zijn verwijderd.

Binnen de afgesproken audit krijg je een analyse van de onderzochte queries en plannen, aandachtspunten rond indexen of locking en concrete vervolgstappen. Aanpassingen en vergelijking met de nulmeting worden vooraf afgebakend.

Bespreek je queryprobleem

Een geplande databasemigratie

Om te beginnen: noem bron- en doelsysteem, globale omvang, betrokken applicaties en de gewenste overstap. Beschrijf welke gegevens en werking gelijk moeten blijven en welke onderbreking bespreekbaar is.

Het onderzoek brengt verschillen en risico’s in kaart, met een voorstel voor validatie van data en applicatiegedrag. Testmigratie, omschakeling en terugval worden als afzonderlijke stappen afgestemd; uitvoering volgt alleen volgens de afgesproken scope.

Bespreek je migratie

Stuur in de eerste aanvraag geen wachtwoorden, toegangssleutels, volledige databasedumps of persoonsgegevens. Eventuele verdere toegang of testdata spreken we afzonderlijk af.

Bekijk de bestaande SQL-demo en haar beperkingen

Wanneer de database de bottleneck wordt.

Databaseproblemen worden duur wanneer ze als symptoom worden behandeld. Eerst wordt gemeten waar de vertraging of complexiteit werkelijk ontstaat.

01

Trage queries

Queries die onder productiebelasting steeds meer tijd, CPU of I/O vragen.

02

Onvoldoende indexering

Indexes die ontbreken, niet gebruikt worden of niet meer aansluiten op de echte querypatronen.

03

Groeiende datasets

Tabellen en workloads die groeien waardoor eerdere keuzes niet langer performant genoeg zijn.

04

Complexe dataflows

Replicatie, imports, migraties en koppelingen waarbij betrouwbaarheid en dataconsistentie cruciaal zijn.

Begin met een afgebakende SQL-queryaudit.

Rechtstreeks met de specialist bepaal je welke queries of workload we onderzoeken. Daarna krijg je een onderbouwd advies, zonder automatisch een volledige herbouw te bestellen.

Trage queries optimaliseren

Laat bestaande queries, indexen en uitvoeringsplannen onderzoeken. Aanpassingen worden na akkoord uitgevoerd en vergeleken met de uitgangssituatie.

Complexe SQL schrijven of corrigeren

Hulp bij joins, rapportages en onjuiste resultaten. De gewenste uitkomst en randgevallen worden eerst vastgelegd, daarna wordt de SQL daarop gecontroleerd.

Databaseproblemen en migraties onderzoeken

Onderzoek van bredere knelpunten of geplande migraties, zoals databasebelasting, locking, verschillen tussen bron en doel en dataconsistentie. Uitvoering en productiecutover worden afzonderlijk afgebakend.

Wat je na de audit ontvangt

  • Een vastgelegde scope met de onderzochte queries, databaseversie, workload en beschikbare nulmetingen.
  • Een analyse van de gevonden oorzaken, relevante uitvoeringsplannen en beperkingen van de beschikbare gegevens.
  • Geprioriteerd verbeteradvies met query- of indexvoorstellen waar de analyse die onderbouwt, inclusief risico’s en een terugvalaanpak.
  • Een verslag van de werkelijk uitgevoerde controles, openstaande validatie en een voorstel voor de volgende stap.

Omvang, toegang, prijs en oplevering spreken we vooraf af. Wijzigingen in productie zijn geen automatisch onderdeel van de audit. Er geldt geen vast snelheidspercentage.

Bespreek je SQL-queryaudit

Gerichte MySQL, MSSQL en SQL-expertise.

Geen brede herbouw als een gerichte databaseverbetering volstaat. De analyse vertrekt vanuit de workload, execution plans en concrete knelpunten.

01

Query-optimalisatie

Complexe of trage SQL analyseren, herschrijven en valideren met EXPLAIN en execution plans.

02

Indexoptimalisatie

Indexes beoordelen op basis van echte filters, joins, sorteringen en toegangspatronen.

03

MySQL, MariaDB & InnoDB

InnoDB-tuning, servergedrag en databaseconfiguratie onderzoeken in functie van de workload.

04

Microsoft SQL Server

MSSQL-queryanalyse, execution plans, indexering en gerichte optimalisatie van bestaande databases.

05

Replicatie & migraties

Datastromen, replicatie en migraties technisch afbakenen met aandacht voor consistentie en herstelbaarheid.

06

Users, roles & privileges

Toegang beperken tot wat nodig is en databasegebruikers, rollen en privileges duidelijk structureren.

Eerst meten, dan optimaliseren.

Een snellere database ontstaat niet door willekeurig indexes of configuratie toe te voegen. De oplossing moet aantoonbaar aansluiten op het echte probleem en mag nieuwe risico’s niet verbergen.

  • 01Execution plans en querygedrag vormen de basis van performancebeslissingen.
  • 02Indexen worden gekozen vanuit echte querypatronen, niet vanuit aannames.
  • 03Wijzigingen worden zo klein en controleerbaar mogelijk gehouden.
  • 04Na optimalisatie wordt opnieuw gemeten om regressies en neveneffecten te detecteren.

Een database migreren met controle over data en risico.

Een MySQL- of SQL-migratie begint met inventarisatie en een testbaar draaiboek. De aanpak hangt af van databron, doelplatform, omvang, afhankelijkheden en toegestane downtime.

  1. 01

    Inventarisatie

    Schema, datavolume, applicatiekoppelingen, jobs en externe afhankelijkheden worden in kaart gebracht.

  2. 02

    Compatibiliteit

    Datatypes, constraints, queries, procedures en indexen worden gecontroleerd op verschillen tussen bron en doel.

  3. 03

    Testmigratie

    Een proefrun maakt doorlooptijd, datakwaliteit en foutpaden zichtbaar voordat productie wordt geraakt.

  4. 04

    Validatie

    Aantallen, relaties, kritieke records en applicatieflows worden voor en na de migratie vergeleken.

  5. 05

    Cutover en rollback

    Het omschakelmoment, downtime-risico en een haalbare terugvalstrategie worden vooraf vastgelegd.

  6. 06

    Controle achteraf

    Na de cutover worden queries, indexen, fouten en performance opnieuw gecontroleerd.

Databasetechnologie in de praktijk.

De primaire focus ligt op MySQL, MariaDB, Microsoft SQL Server en SQL-performance. PostgreSQL kan aanvullend worden ondersteund wanneer dat binnen de opdracht past.

  • MySQL
  • MariaDB
  • Microsoft SQL Server
  • MSSQL
  • SQL
  • InnoDB
  • MySQL Shell
  • PostgreSQL
  • Linux

Eigen technische demonstratie, geen klantcase

Een samengestelde index beoordelen met dezelfde query.

Dit reproduceerbare voorbeeld gebruikt acht fictieve bestellingen. Het toont hoe je een indexvoorstel onderzoekt en resultaten controleert, niet hoeveel sneller een klantdatabase is geworden.

  1. Situatie

    Een overzicht selecteert de bestellingen van één klant binnen een dag en sorteert op tijdstip en ID. De testtabel begint alleen met een primary key.

  2. Analyse en wijziging

    Vergelijk EXPLAIN vóór en na een samengestelde index op customer_id, created_at en id. De SELECT blijft identiek: alleen de toegangsmogelijkheid verandert.

  3. Correctheid controleren

    Beide SELECT-statements horen de ID’s 7, 4, 3 en 2 in die volgorde terug te geven. De fixtures bevatten datumgrenzen, een andere klant en twee identieke tijdstippen.

  4. Resultaat interpreteren

    Controleer de gekozen index en geschatte rijen. Acht rijen zijn geen performancebenchmark: de optimizer kan nog steeds een tabelscan kiezen. Meet snelheid, schrijfkosten en opslag daarna met een representatieve workload.

Voer het volledige voorbeeld in één nieuwe sessie uit in een aparte MySQL- of MariaDB-testdatabase, nooit in productie. De tijdelijke tabel verdwijnt wanneer je de sessie sluit. Dit is geen SQL Server-script.

Bekijk het volledige SQL-voorbeeld met testdata
-- Synthetic demonstration for a NEW session in a separate MySQL/MariaDB test database.
-- Never run this in production. Requires CREATE TEMPORARY TABLES permission.
-- Stop on the first error. Do not use a client option that continues after errors.
-- The table exists only in this session. Close the session before rerunning.
-- No measured speed improvement is claimed. EXPLAIN reports estimates, not timings.

CREATE TEMPORARY TABLE cg_query_demo_orders (
    id INTEGER NOT NULL PRIMARY KEY,
    customer_id INTEGER NOT NULL,
    created_at DATETIME NOT NULL
);

INSERT INTO cg_query_demo_orders (id, customer_id, created_at) VALUES
    (1, 42, '2026-08-31 23:59:59'),
    (2, 42, '2026-09-01 00:00:00'),
    (3, 42, '2026-09-01 12:00:00'),
    (4, 42, '2026-09-01 12:00:00'),
    (5, 42, '2026-09-02 00:00:00'),
    (6, 7, '2026-09-01 12:00:00'),
    (7, 42, '2026-09-01 23:59:59'),
    (8, 42, '2026-09-02 00:00:01');

-- Baseline: inspect the plan and return the actual rows.
EXPLAIN SELECT id, customer_id, created_at
FROM cg_query_demo_orders
WHERE customer_id = 42
  AND created_at >= '2026-09-01 00:00:00'
  AND created_at < '2026-09-02 00:00:00'
ORDER BY created_at DESC, id DESC;

SELECT id, customer_id, created_at
FROM cg_query_demo_orders
WHERE customer_id = 42
  AND created_at >= '2026-09-01 00:00:00'
  AND created_at < '2026-09-02 00:00:00'
ORDER BY created_at DESC, id DESC;

-- Candidate index, not a recommendation to add this index to production blindly.
CREATE INDEX cg_query_demo_customer_created_id
ON cg_query_demo_orders (customer_id, created_at, id);

-- Same SELECT after the index. Expected IDs before and after: 7, 4, 3, 2.
-- A table scan on eight rows can be a valid optimiser decision.
EXPLAIN SELECT id, customer_id, created_at
FROM cg_query_demo_orders
WHERE customer_id = 42
  AND created_at >= '2026-09-01 00:00:00'
  AND created_at < '2026-09-02 00:00:00'
ORDER BY created_at DESC, id DESC;

SELECT id, customer_id, created_at
FROM cg_query_demo_orders
WHERE customer_id = 42
  AND created_at >= '2026-09-01 00:00:00'
  AND created_at < '2026-09-02 00:00:00'
ORDER BY created_at DESC, id DESC;

Geen gemeten klantresultaat of gegarandeerde snelheidswinst. De automatische regressietest controleert resultaatgelijkheid op SQLite, niet het uitvoeringsplan of de snelheid van MySQL, MariaDB of SQL Server.

MySQL-documentatie over samengestelde indexen

Veelgestelde vragen over database-optimalisatie

Helpt Codegenie alleen met MySQL?

Nee. De hoofdexpertise ligt bij MySQL, MariaDB en Microsoft SQL Server. PostgreSQL kan aanvullend worden ondersteund afhankelijk van de concrete vraag.

Kun je één trage query onderzoeken zonder de hele applicatie te herbouwen?

Ja. Een afgebakende query- of performanceanalyse is vaak de beste eerste stap. Alleen wanneer het probleem structureler blijkt, wordt een bredere wijziging voorgesteld.

Kun je bestaande indexes en execution plans controleren?

Ja. Bestaande querypatronen, EXPLAIN of execution plans en indexes kunnen samen worden beoordeeld om onnodig werk en bottlenecks te vinden.

Garandeert database-optimalisatie een vast snelheidspercentage?

Nee. Het effect hangt af van data, workload, infrastructuur en applicatiegedrag. Daarom wordt eerst gemeten en wordt het resultaat na de wijziging opnieuw gevalideerd.

Een trage query of databaseprobleem laten onderzoeken?

Beschrijf kort welke database je gebruikt, waar het probleem zichtbaar wordt en welke impact je vandaag merkt. Codegenie bekijkt de kleinste verstandige volgende stap.