Česky na konci článku.
Database performance problems are rarely caused by a single parameter.
When an application becomes slow, the first reaction is often:
“The database needs more CPU.”
Or:
“We need another index.”
Sometimes that is correct. Very often, it is not.
Modern Database Performance Tuning requires understanding the complete workload: SQL execution, concurrency, memory, I/O, storage latency, connection management, application behavior and database architecture.
Oracle’s current performance methodology explicitly emphasizes that performance problems are commonly caused by resource contention or resource exhaustion, and that performance should be designed into the system rather than treated only as a production emergency.
For a Senior Database Administrator, performance tuning is therefore not simply about making individual queries faster.
It is about making the entire database platform predictable under load.
1. Start With the Workload, Not the Configuration
One of the biggest mistakes in database performance tuning is changing configuration parameters before understanding the workload.
Before changing anything, a DBA should establish:
- What is slow?
- When did it become slow?
- Which SQL statements are responsible?
- Is the problem constant or intermittent?
- Did workload volume change?
- Did the application change?
- Did the execution plan change?
- Is the database waiting for CPU, memory, I/O or locks?
- Is the storage subsystem responding normally?
The first objective is therefore:
Measure → Identify → Hypothesize → Change → Validate
Not:
Change → Restart → Hope
2. SQL Is Usually the First Place to Investigate
A database can have powerful hardware and still perform badly because of inefficient SQL.
Typical problems include:
- missing indexes
- inappropriate indexes
- inefficient joins
- excessive full table scans
- poor predicates
- implicit data type conversions
- excessive sorting
- inefficient pagination
- unnecessary columns
- repeated queries
- poor execution plans
MySQL’s current documentation similarly emphasizes that database performance depends on table design, queries, indexes, storage engines and memory configuration.
A useful performance investigation therefore begins with the SQL itself.
3. Execution Plans Matter More Than Query Text
Two SQL statements can look almost identical while producing completely different execution plans.
Consider:
The database could potentially use:
or:
The SQL text alone does not tell us which path the optimizer selected.
This is why a DBA should always investigate the actual execution plan when analyzing an important query.
For Oracle, tools such as AWR, ASH, ADDM and SQL Tuning Advisor are part of Oracle’s performance tuning toolkit.
4. An Index Is Not Automatically a Performance Improvement
Adding indexes is one of the most common DBA recommendations.
But indexes have a cost.
Every additional index can increase:
- storage consumption
- INSERT cost
- UPDATE cost
- DELETE cost
- maintenance overhead
- write I/O
The correct question is not:
“Can we add an index?”
It is:
“Does this index improve the workload enough to justify its cost?”
A production DBA must consider both read and write workloads.
For example:
Database optimization is always a trade-off.
5. CPU Is Not Always the Problem
A database server showing 90% CPU utilization does not automatically mean:
“Add more CPU.”
The CPU may be high because of:
- inefficient SQL
- excessive parsing
- bad execution plans
- too many concurrent queries
- inefficient application behavior
- missing indexes
- unnecessary calculations
Conversely, a database with only 30% CPU utilization can still be extremely slow because it is waiting for:
- storage
- locks
- network
- memory
- another database session
This is why resource utilization alone is not enough.
The DBA needs to understand what the database is actually waiting for.
6. Database Wait Events Tell the Real Story
One of the most valuable skills of an experienced DBA is understanding wait events.
Instead of asking:
“Why is CPU high?”
ask:
“What is preventing sessions from making progress?”
Possible causes include:
A high database response time is usually the result of one or more bottlenecks somewhere in this chain.
This is particularly important in Oracle environments, where wait-event analysis and tools such as ASH and AWR can provide detailed visibility into workload behavior.
7. Connection Management Can Become a Database Bottleneck
Applications often create more database connections than they actually need.
This can lead to:
- memory pressure
- excessive session management
- increased context switching
- connection storms
- increased contention
A better architecture frequently uses a connection pool:
Oracle’s current SQL tuning guidance specifically recommends connection pooling for multi-tier applications rather than repeatedly establishing database connections for individual requests.
The same principle applies across database platforms.
8. PostgreSQL: Don’t Ignore Memory, WAL and VACUUM
PostgreSQL performance tuning requires understanding its internal architecture.
Important areas include:
- shared buffers
- work memory
- WAL
- checkpoints
- autovacuum
- table bloat
- indexes
- query planner
- statistics
- connections
- replication
A slow PostgreSQL query may not be caused by SQL alone.
The DBA should also investigate:
PostgreSQL performance is therefore a combination of database configuration, workload characteristics and infrastructure behavior.
9. MySQL: InnoDB and the Buffer Pool
For MySQL environments, InnoDB is central to performance analysis.
Important areas include:
- InnoDB buffer pool
- redo logs
- transactions
- locking
- indexes
- query execution
- I/O
- connection management
The buffer pool should be large enough to cache frequently accessed data without causing the operating system to start paging.
MySQL’s documentation specifically highlights the importance of correctly sizing memory areas such as the InnoDB buffer pool and considering the storage engine’s characteristics when tuning performance.
10. Oracle: AWR and ASH Are Powerful, But They Need Interpretation
Oracle provides sophisticated performance diagnostics.
AWR can help identify workload patterns.
ASH provides information about active sessions.
ADDM can identify potential performance bottlenecks.
SQL Tuning Advisor can provide recommendations for SQL optimization.
But tools do not replace DBA expertise.
A report may tell you:
The next question is:
Why is I/O the bottleneck?
It could be:
- poor SQL
- missing indexes
- insufficient memory
- slow storage
- excessive workload
- inefficient execution plans
The tool identifies evidence.
The DBA determines the cause.
11. Storage Latency Can Destroy Database Performance
Modern CPUs are extremely fast.
Storage is often much slower.
A database can therefore spend significant time waiting for I/O.
Important metrics include:
- latency
- IOPS
- throughput
- queue depth
- read/write ratio
A simplified model:
If storage latency increases dramatically, database response time can increase even when CPU utilization remains relatively low.
This is why database performance analysis should include the storage layer.
12. Don’t Solve a Capacity Problem With Configuration Alone
Sometimes the workload has simply outgrown the infrastructure.
For example:
Changing a memory parameter may provide temporary relief.
But if workload growth continues, the underlying architecture needs to change.
Possible solutions include:
- partitioning
- better indexing
- query optimization
- larger infrastructure
- read replicas
- caching
- workload separation
- database sharding
- application redesign
Oracle’s current performance guidance also warns against treating additional hardware as a permanent solution when underlying workload or application inefficiencies remain.
13. Performance Testing Must Use Realistic Data
A query that works well against:
may behave very differently against:
Performance testing should therefore consider:
- realistic data volumes
- realistic data distribution
- realistic concurrency
- realistic transaction rates
- realistic indexes
- realistic storage
Oracle’s current guidance specifically recommends testing with realistic data volumes and distributions rather than relying on small development datasets.
This is one reason why production performance problems often appear immediately after an application scales.
14. Database Performance Is a System Problem
A database does not operate in isolation.
The complete path is:
A DBA who only looks at the database may miss the real problem.
For example:
The problem might be network latency between the application and database.
Or:
The storage subsystem may be the real bottleneck.
Senior DBA troubleshooting therefore requires cross-layer analysis.
15. Automation Should Be Part of Performance Engineering
Once a performance problem has been understood, the next question should be:
Can we detect this automatically next time?
Automation can help with:
- baseline collection
- query monitoring
- alerting
- configuration validation
- capacity forecasting
- performance regression detection
- health checks
For example:
This transforms performance management from reactive troubleshooting into proactive engineering.
16. AI Will Help — But It Won’t Replace the DBA
Database tuning is becoming increasingly suitable for AI-assisted analysis.
Research published in 2026 is already exploring automated database configuration tuning using workload-specific learning approaches across MySQL and PostgreSQL. One recent study reported improved tuning results compared with tested alternatives, while also highlighting that configuration tuning remains a challenging, high-dimensional problem.
AI can help identify:
- unusual workloads
- query regressions
- configuration anomalies
- correlations between metrics
- potential tuning candidates
But the DBA still needs to understand:
What is safe to change?
What is the business impact?
Could the optimization create another bottleneck?
Automation can recommend.
A senior DBA remains responsible for the decision.
A Practical Performance Tuning Workflow
A mature DBA team should have a repeatable methodology.
Step 1 — Establish the symptom
What exactly is slow?
Step 2 — Establish the baseline
What does normal look like?
Step 3 — Identify the bottleneck
CPU? I/O? Locks? SQL? Memory? Network?
Step 4 — Find the root cause
Do not stop at the first visible symptom.
Step 5 — Change one important variable
Avoid changing ten parameters simultaneously.
Step 6 — Measure the result
Did performance actually improve?
Step 7 — Validate side effects
Did write performance, memory or another workload get worse?
Step 8 — Document the solution
Future DBAs should understand what happened.
Step 9 — Automate detection where possible
The next incident should be detected earlier.
The Difference Between a DBA and a Performance Engineer
A traditional approach might be:
“The database is slow. Increase memory.”
A performance engineer asks:
“What is consuming the available resources, and why?”
That difference is critical.
The first approach changes infrastructure.
The second investigates the system.
The best Database Administrators combine both approaches.
Final Takeaway
Database Performance Tuning is not about finding one magic parameter.
It is a structured engineering discipline.
The strongest DBAs understand the relationship between:
SQL + Execution Plans + CPU + Memory + I/O + Storage + Concurrency + Application Architecture
Oracle, PostgreSQL and MySQL each provide different diagnostic tools and internal mechanisms, but the fundamental methodology remains similar:
Measure first. Understand the workload. Identify the real bottleneck. Change deliberately. Validate the result.
A database that is fast today but unpredictable under tomorrow’s workload is not truly optimized.
The goal of a senior Database Administrator is therefore not simply to make a database faster.
It is to make database performance predictable, measurable and sustainable as the business grows.
About the Author
Tomas Solar
Principal Database Reliability Engineer
20+ years of experience with Oracle, PostgreSQL, MySQL, SQL Server and MongoDB.
Specialized in Database Administration, Performance Engineering, High Availability, Disaster Recovery, Database Reliability, Automation, Database Migration and Database Architecture.
Good database performance is not achieved by adding resources blindly. It comes from understanding the workload and removing the real bottleneck.
Ladění výkonu databází v roce 2026: Praktický průvodce pro Senior Database Administrátory
Problémy s výkonem databáze jen zřídka způsobuje jediný parametr.
Když aplikace začne být pomalá, první reakcí často bývá:
„Databáze potřebuje více CPU.“
Nebo:
„Musíme přidat další index.“
Někdy je to správně. Velmi často ale ne.
Moderní Database Performance Tuning vyžaduje pochopení celého workloadu – SQL dotazů, concurrency, paměti, I/O, storage latency, connection managementu, chování aplikace i databázové architektury.
Pro Senior Database Administrátora proto performance tuning není pouze o zrychlení jednotlivých SQL dotazů.
Je to především snaha vytvořit databázovou platformu, jejíž chování je předvídatelné i při vysokém zatížení.
1. Začněte workloadem, ne konfigurací
Jednou z nejčastějších chyb při ladění databáze je změna konfiguračních parametrů ještě před pochopením workloadu.
Nejdříve je potřeba zjistit:
- Co je pomalé?
- Kdy problém začal?
- Které SQL dotazy jsou za problém zodpovědné?
- Je problém trvalý, nebo pouze občasný?
- Změnil se objem workloadu?
- Změnila se aplikace?
- Změnil se execution plan?
- Čeká databáze na CPU, paměť, I/O nebo locky?
- Funguje storage normálně?
Základní postup by měl být:
Measure → Identify → Hypothesize → Change → Validate
tedy:
Změřit → Identifikovat → Stanovit hypotézu → Změnit → Ověřit
Ne:
Změnit → Restartovat → Doufat
2. SQL je často první místo, kde hledat problém
Databáze může mít velmi výkonný hardware a přesto pracovat pomalu kvůli neefektivnímu SQL.
Typické problémy:
- chybějící indexy
- nevhodné indexy
- neefektivní JOINy
- zbytečné full table scany
- špatné podmínky
- implicitní konverze datových typů
- nadměrné řazení
- neefektivní stránkování
- načítání nepotřebných sloupců
- opakované dotazy
- nevhodné execution plans
Proto by měl seniorní DBA při analýze výkonu začít právě u SQL.
3. Execution Plan je důležitější než samotný SQL dotaz
Dva SQL dotazy mohou vypadat téměř stejně a přitom mít úplně odlišný execution plan.
Například:
Databáze může použít:
nebo:
Samotný SQL text nám neřekne, kterou cestou se optimizer vydal.
Proto je při analýze důležité sledovat skutečný execution plan.
U Oracle jsou pro diagnostiku výkonu důležité například AWR, ASH, ADDM a SQL Tuning Advisor.
4. Index automaticky neznamená lepší výkon
Přidávání indexů je jedním z nejčastějších doporučení DBA.
Indexy ale něco stojí.
Každý další index může znamenat:
- větší spotřebu storage
- vyšší náklady při INSERT
- vyšší náklady při UPDATE
- vyšší náklady při DELETE
- další maintenance
- další I/O
Správná otázka proto není:
„Můžeme přidat index?“
Ale:
„Přinese tento index dostatečné zrychlení, aby ospravedlnil své náklady?“
Je potřeba sledovat celý workload.
Databázová optimalizace je vždy určitý kompromis.
5. Vysoké CPU nemusí znamenat, že potřebujete více CPU
Databázový server může mít například 90% využití CPU.
To ale automaticky neznamená:
„Přidejme CPU.“
Vysoké CPU může být způsobeno:
- neefektivním SQL
- příliš mnoha parse operacemi
- špatným execution planem
- vysokou konkurencí
- nevhodným chováním aplikace
- chybějícími indexy
- zbytečnými výpočty
Naopak databáze s využitím CPU pouze 30 % může být velmi pomalá, protože čeká na:
- storage
- locky
- síť
- paměť
- jinou databázovou session
Proto samotné využití CPU nestačí.
DBA musí zjistit, na co databáze skutečně čeká.
6. Wait Events často ukážou skutečný problém
Jednou z nejcennějších schopností zkušeného DBA je práce s wait events.
Místo otázky:
„Proč je CPU vysoké?“
je často lepší se ptát:
„Co brání session v pokračování?“
Příčinou může být:
Vysoká response time databáze je často výsledkem bottlenecku v jedné nebo více těchto oblastí.
U Oracle je právě analýza wait events velmi důležitou součástí diagnostiky pomocí AWR a ASH.
7. Connection management může být bottleneck
Aplikace někdy vytváří více databázových spojení, než skutečně potřebuje.
To může způsobovat:
- tlak na paměť
- vysoké nároky na správu session
- connection storms
- větší contention
- zbytečný overhead
Vhodnější architektura často využívá connection pool:
Connection pooling umožňuje efektivněji využívat existující databázová spojení a omezit zbytečné vytváření nových sessions.
8. PostgreSQL: nezanedbávejte paměť, WAL a VACUUM
U PostgreSQL je potřeba rozumět jeho interní architektuře.
Mezi důležité oblasti patří:
- shared buffers
- work_mem
- WAL
- checkpointy
- autovacuum
- table bloat
- indexy
- query planner
- statistiky
- počet connections
- replikace
Pomalý PostgreSQL dotaz nemusí být způsoben pouze SQL.
DBA by měl analyzovat celý řetězec:
PostgreSQL performance je kombinací konfigurace databáze, charakteristik workloadu a infrastruktury.
9. MySQL: InnoDB a Buffer Pool
U MySQL je pro performance tuning zásadní InnoDB.
Důležité oblasti zahrnují:
- InnoDB Buffer Pool
- redo log
- transakce
- locking
- indexy
- query execution
- I/O
- connection management
Buffer Pool musí být dostatečně velký, aby dokázal efektivně cacheovat často používaná data, ale zároveň nesmí způsobit tlak na systémovou paměť.
U MySQL je proto důležité při ladění výkonu sledovat nejen SQL, ale také paměť, storage a chování InnoDB.
10. Oracle: AWR a ASH jsou silné nástroje, ale potřebují DBA
Oracle nabízí velmi pokročilé nástroje pro diagnostiku výkonu.
AWR pomáhá analyzovat workload a jeho vývoj.
ASH poskytuje informace o aktivních sessions.
ADDM může identifikovat potenciální bottlenecky.
SQL Tuning Advisor může nabídnout doporučení pro optimalizaci SQL.
Nástroje ale nenahradí zkušeného DBA.
Report může například ukázat:
Další otázka ale musí být:
Proč je I/O bottleneck?
Může jít o:
- špatné SQL
- chybějící indexy
- nedostatek paměti
- pomalý storage
- příliš vysoký workload
- špatný execution plan
Nástroj poskytne data.
DBA musí najít příčinu.
11. Storage latency může zničit výkon databáze
Moderní CPU jsou velmi rychlé.
Storage je často výrazně pomalejší.
Databáze proto může strávit značnou část času čekáním na I/O.
Důležité metriky jsou:
- latency
- IOPS
- throughput
- queue depth
- poměr read/write
Zjednodušeně:
Pokud se výrazně zvýší storage latency, může se dramaticky zvýšit response time databáze, i když CPU zůstane relativně nízké.
Proto musí performance tuning zahrnovat také storage layer.
12. Kapacitní problém nevyřešíte pouze změnou konfigurace
Někdy workload jednoduše přeroste infrastrukturu.
Například:
Změna memory parametru může přinést krátkodobou úlevu.
Pokud ale workload dál roste, musí se změnit také architektura.
Možná řešení:
- partitioning
- lepší indexy
- optimalizace SQL
- výkonnější infrastruktura
- read replicas
- caching
- oddělení workloadů
- sharding
- změna návrhu aplikace
Senior DBA musí rozlišit mezi konfiguračním problémem a skutečným kapacitním problémem.
13. Performance testing musí používat realistická data
Dotaz, který funguje dobře nad:
se může chovat úplně jinak nad:
Performance testing by proto měl používat:
- realistický objem dat
- realistickou distribuci dat
- realistickou concurrency
- realistický počet transakcí
- realistické indexy
- realistický storage
Právě proto se některé problémy objeví až v produkci.
Vývojové prostředí může mít několik tisíc řádků.
Produkce může mít několik stovek milionů.
14. Database Performance je systémový problém
Databáze nefunguje izolovaně.
Celý řetězec může vypadat:
Pokud DBA sleduje pouze databázi, může skutečnou příčinu přehlédnout.
Například:
Problém může být v síťové latenci mezi aplikací a databází.
Nebo:
Skutečným bottleneckem může být storage.
Senior DBA proto potřebuje cross-layer troubleshooting.
15. Automatizace patří i do performance engineeringu
Když problém vyřešíme, měli bychom si položit otázku:
„Dokážeme příště tento problém odhalit automaticky?“
Automatizace může pomoci například s:
- sběrem baseline
- monitoringem SQL
- alertingem
- kontrolou konfigurace
- capacity forecasting
- detekcí performance regression
Například:
Tím se performance management mění z reaktivního troubleshooting na proaktivní engineering.
16. AI pomůže, ale DBA nenahradí
AI bude stále více pomáhat při analýze databázového výkonu.
Může například pomoci hledat:
- neobvyklý workload
- regresi SQL
- konfigurační anomálie
- korelace mezi metrikami
- kandidáty na optimalizaci
Ale seniorní DBA stále musí rozhodnout:
Je tato změna bezpečná?
Jaký bude její dopad na business?
Nevytvoří optimalizace jiný bottleneck?
AI může doporučit řešení.
Zodpovědnost za rozhodnutí ale zůstává na DBA.
Praktický workflow pro Database Performance Tuning
Vyspělý DBA tým by měl mít opakovatelnou metodiku.
1. Určit problém
Co přesně je pomalé?
2. Vytvořit baseline
Jak vypadá normální stav?
3. Najít bottleneck
CPU? I/O? Locky? SQL? Memory? Network?
4. Najít root cause
Nezastavit se u prvního viditelného symptomu.
5. Změnit jednu důležitou věc
Neměnit deset parametrů najednou.
6. Změřit výsledek
Zlepšil se skutečně výkon?
7. Zkontrolovat vedlejší dopady
Nezhoršil se jiný workload?
8. Dokumentovat řešení
Budoucí DBA musí vědět, co se stalo.
9. Automatizovat detekci
Příští incident by měl být odhalen dříve.
Rozdíl mezi DBA a Performance Engineerem
Tradiční přístup:
„Databáze je pomalá. Přidejme paměť.“
Performance Engineer se ptá:
„Co spotřebovává dostupné zdroje a proč?“
To je zásadní rozdíl.
První přístup mění infrastrukturu.
Druhý přístup analyzuje systém.
Nejlepší Database Administrators umí oba přístupy kombinovat.
Závěr
Database Performance Tuning není hledání jednoho magického parametru.
Je to systematická technická disciplína.
Silný DBA rozumí vztahu mezi:
SQL + Execution Plans + CPU + Memory + I/O + Storage + Concurrency + Application Architecture
Oracle, PostgreSQL i MySQL mají vlastní diagnostické nástroje a specifické interní mechanismy. Základní metodika je ale podobná:
Nejdříve měřit. Porozumět workloadu. Najít skutečný bottleneck. Měnit promyšleně. Ověřit výsledek.
Databáze, která je rychlá dnes, ale při zítřejším růstu workloadu zcela nepředvídatelná, není skutečně optimalizovaná.
Cílem seniorního Database Administrátora proto není pouze databázi zrychlit.
Cílem je vytvořit výkon databáze, který je:
předvídatelný, měřitelný a dlouhodobě udržitelný.
O autorovi
Tomas Solar
Principal Database Reliability Engineer
Více než 20 let zkušeností s Oracle, PostgreSQL, MySQL, SQL Server a MongoDB.
Specializace na Database Administration, Performance Engineering, High Availability, Disaster Recovery, Database Reliability, Automation, Database Migration a Database Architecture.
Dobrý výkon databáze nevzniká slepým přidáváním zdrojů. Vzniká pochopením workloadu a odstraněním skutečného bottlenecku.