SQL Performance

Improve a measured workload while preserving its result, durability, and concurrency contract. Database size is context, not a diagnosis. A 100 MB–1 GB database can require careful query work without needing partitioning or sharding.

Frame a bounded investigation

Inspect existing SQL, schema/migrations, application timings, plans, and relevant settings. Establish:

• Engine and actual runtime/server version, driver and prepared-statement behavior, deployment/storage, CPU/memory budget, and connection/concurrency limits.
• The slow operation and its accepted result; query text/identity and representative bind values without disclosing sensitive data.
• Row counts, table/index bytes, row width, data skew, hot working set, result bytes, read/write mix, and likely growth.
• A useful target: latency at stated concurrency, import/export duration, memory ceiling, or storage/write budget. Keep this proportionate to the user's problem.

Separate pool wait, lock wait, SQL execution, result transfer, decoding/materialization, and downstream application work. Use available evidence before adding instrumentation. If the slow component is still unknown, use performance for that investigation; an already reproducible SQL problem does not need an arbitrary monitoring delay.

Capture a comparable baseline

Use representative data and parameters, including large or skewed groups. Record version, schema/indexes, statistics state, settings, dataset scale, cache/warm-up conditions, concurrency, repetitions, and measurement scope. Generate or sanitize representative data when real data is unavailable; state which distributions it does not reproduce.