SQL expertise for MySQL, MariaDB & SQL Server
Slow SQL queries, reports, applications or a planned migration? Codegenie investigates query plans, indexes and data consistency in MySQL, MariaDB and Microsoft SQL Server.
Start with the situation you want investigated. In the contact form, choose the SQL query analysis or database problem category and say whether your question concerns queries or a migration.
To start: describe which operation gets stuck, when it happens and which database and version you use. You may share an anonymised query, table structure or execution plan with sensitive values removed.
Within the agreed audit scope, you receive an analysis of the reviewed queries and plans, points to investigate around indexes or locking and concrete next steps. Changes and comparison with the baseline are scoped in advance.
Discuss your query problemTo start: name the source and target systems, approximate size, affected applications and intended transition. Describe which data and behaviour must remain consistent and what downtime can be discussed.
The investigation identifies differences and risks, with a proposal for validating data and application behaviour. A test migration, cutover and rollback are agreed as separate steps; implementation follows only within the agreed scope.
Discuss your migrationDo not send passwords, access keys, complete database dumps or personal data in your initial enquiry. Any further access or test data will be agreed separately.
Explore the existing SQL demo and its limitationsDatabase problems become expensive when only the symptom is treated. The first step is measuring where the delay or complexity actually originates.
Queries that consume increasing time, CPU or I/O under production workloads.
Indexes that are missing, unused or no longer aligned with real query patterns.
Tables and workloads that grow until earlier design choices are no longer performant enough.
Replication, imports, migrations and integrations where reliability and data consistency are critical.
Work directly with the specialist to define the queries or workload to investigate. You receive evidence-based advice without automatically commissioning a complete rebuild.
Have existing queries, indexes and execution plans investigated. Changes are implemented after approval and compared with the baseline.
Help with joins, reports and incorrect results. The required output and edge cases are defined first, then the SQL is checked against them.
Investigate wider bottlenecks or planned migrations, including database load, locking, source-to-target differences and data consistency. Execution and production cutover are scoped separately.
Scope, access, price and deliverables are agreed in advance. Production changes are not automatically included in the audit. No fixed percentage speed improvement is promised.
Discuss your SQL query auditNo broad rebuild when a targeted database improvement is enough. Analysis starts from the workload, execution plans and concrete bottlenecks.
Analyse, rewrite and validate complex or slow SQL using EXPLAIN and execution plans.
Evaluate indexes against real filters, joins, sorting and access patterns.
Investigate InnoDB tuning, server behaviour and database configuration against the actual workload.
SQL Server query analysis, execution plans, indexing and targeted optimisation of existing databases.
Scope data flows, replication and migrations with attention to consistency and recoverability.
Restrict access to what is required and structure database users, roles and privileges clearly.
A faster database does not come from adding random indexes or configuration changes. The solution must address the measured problem without hiding new risks.
A MySQL or SQL migration starts with an inventory and a testable runbook. The approach depends on the source, target platform, volume, dependencies and acceptable downtime.
Schema, data volume, application integrations, jobs and external dependencies are mapped.
Data types, constraints, queries, procedures and indexes are checked for differences between source and target.
A trial run exposes duration, data-quality issues and failure paths before production is affected.
Counts, relationships, critical records and application flows are compared before and after migration.
The switchover, downtime risk and a feasible rollback strategy are defined in advance.
Queries, indexes, errors and performance are reviewed again after cutover.
The primary focus is MySQL, MariaDB, Microsoft SQL Server and SQL performance. PostgreSQL can also be supported where it fits the assignment.
In-house technical demonstration, not a client case
This reproducible example uses eight fictional orders. It shows how to investigate an index proposal and check results, not how much faster a client database became.
An overview selects one customer’s orders within a day and sorts by timestamp and ID. The test table starts with only a primary key.
Compare EXPLAIN before and after a composite index on customer_id, created_at and id. The SELECT stays identical: only the available access path changes.
Both SELECT statements should return IDs 7, 4, 3 and 2 in that order. The fixtures include date boundaries, another customer and two identical timestamps.
Check the chosen index and estimated rows. Eight rows are not a performance benchmark: the optimiser may still choose a table scan. Measure speed, write costs and storage with a representative workload afterwards.
Run the complete example in one new session in a separate MySQL or MariaDB test database, never in production. The temporary table disappears when the session closes. This is not a SQL Server script.
-- 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;
No measured client result or guaranteed speed improvement. The automated regression test checks result equivalence on SQLite, not the execution plan or speed of MySQL, MariaDB or SQL Server.
These pages address the same underlying question and help you choose the right project scope.
Codegenie builds maintainable connections between applications, data sources and external services around a concrete business process.
View serviceFor recurring bugs, outdated versions, slow pages, difficult deployments, missing documentation or extensions that need proper investigation first.
View serviceCodegenie builds customer portals, dashboards, workflows and platforms with accounts, permissions, data and external integrations.
View serviceExplore index choices, Eloquent, query plans and migration checks. These articles explain the analysis and its limits with examples, not invented client results.
Evaluate a composite index against filters, ordering and execution plans. Check write costs and result correctness as well.
Investigate relationship queries in a Laravel list. Apply targeted eager loading and check query counts, missing relations and pagination.
Use a reproducible example to read a MySQL query plan, investigate an index proposal and compare results.
Combine execution plans, logical reads and controlled tests. A seek or a missing-index suggestion alone does not prove an improvement.
Prepare a MySQL migration with a restore test, comparable measurements, data-content checks and a feasible rollback strategy.
No. The main expertise covers MySQL, MariaDB and Microsoft SQL Server. PostgreSQL can also be supported depending on the specific requirement.
Yes. A scoped query or performance analysis is often the best first step. A broader change is only proposed when the problem proves structural.
Yes. Existing query patterns, EXPLAIN or execution plans and indexes can be assessed together to identify unnecessary work and bottlenecks.
No. The effect depends on data, workload, infrastructure and application behaviour. That is why performance is measured first and validated again after the change.
Briefly describe the database you use, where the problem appears and the impact you see today. Codegenie will assess the smallest sensible next step.