Use the MariaDB Slow Query Log for Better Diagnosis

The MariaDB slow query log is most useful as a controlled evidence source, not as a permanent bucket for every statement that looks suspicious. Configured well, it reveals recurring query shapes, rows examined, execution time, temporary-table use, filesorts, and optimizer-plan signals. Configured carelessly, it can fill a filesystem, expose customer data, add unnecessary I/O, and bury one actionable query beneath millions of harmless entries.

The word “slow” also needs context. A query taking 300 milliseconds may be disastrous when called 2,000 times per second, while a nightly 20-second report may be acceptable. A statement can be fast in the log because caches are warm but still examine millions of rows. Lock waits, result transfer, client think time, and concurrency can make application latency differ from the server-side number.

This guide shows how to audit, enable, scope, secure, rotate, and analyze the slow query log on modern MariaDB. It explains name changes introduced in MariaDB 10.11, selects thresholds from service objectives, uses extended statistics safely, converts entries into query families, validates fixes with execution plans, and leaves a rollback path. The goal is diagnosis that produces a verified change, not simply a larger log file.

Understand what the slow query log records

At its simplest, MariaDB records a completed statement when its execution time exceeds the configured threshold and it passes any row, statement, and plan filters. A typical file entry can include:

Timestamp and connection identity.
Schema and thread ID.
Query execution time and lock time.
Rows sent and rows examined.
The SQL text.
Optional query-plan, engine, warning, or EXPLAIN detail.

Exact fields depend on MariaDB version, log_slow_verbosity, output destination, and statement type. Never build a parser from one copied example without testing the exact server format.

The log records statements after they finish. It cannot warn you in time about an active runaway query by itself. For current activity, combine it with SHOW FULL PROCESSLIST, information_schema.PROCESSLIST, Performance Schema, application tracing, or a monitoring product.

The global Slow_queries status counter counts statements exceeding long_query_time even when the slow query log is disabled. It can reveal a trend but contains no query text:

SHOW GLOBAL STATUS LIKE 'Slow_queries';
SHOW GLOBAL STATUS LIKE 'Uptime';

Use interval deltas rather than dividing one lifetime total and assuming workload was constant.

Know the MariaDB 10.11 naming changes

MariaDB 10.11 standardized several names. The modern names include:

Modern name	Earlier name or alias	Purpose
`log_slow_query`	`slow_query_log`	Enable or disable logging
`log_slow_query_file`	`slow_query_log_file`	File destination
`log_slow_query_time`	`long_query_time`	Execution-time threshold
`log_slow_min_examined_row_limit`	`min_examined_row_limit`	Minimum examined rows

The older names remain useful on long-term-support releases and are aliases on newer versions where documented. Configuration management that spans releases should detect support rather than blindly using one vocabulary.

Inspect the running server:

SELECT VERSION(), @@version_comment;

SHOW GLOBAL VARIABLES WHERE Variable_name IN (
  'log_slow_query',
  'slow_query_log',
  'log_slow_query_file',
  'slow_query_log_file',
  'log_slow_query_time',
  'long_query_time',
  'log_slow_min_examined_row_limit',
  'min_examined_row_limit',
  'log_output',
  'log_slow_filter',
  'log_slow_verbosity',
  'log_slow_rate_limit'
);

Duplicate alias rows are normal. Store one canonical setting per supported release in configuration to keep reviews understandable.

Define the diagnostic question first

Before enabling anything, write down what you are testing. Examples:

Which query families cause the checkout API's P99 latency spike?
Which statements create disk temporary tables during the hourly report?
Which tenant values cause a normally fast digest to examine millions of rows?
Did a new index reduce total rows examined without increasing write latency?
Is replica lag caused by read workload, applied writes, or an administrative statement?

This determines the threshold, capture duration, filters, verbosity, and workload segment. “Find slow SQL” is too broad to control volume or define success.

Record a time window in UTC, deployment version, traffic rate, affected endpoint, server role, and baseline service metrics. The log is much more valuable when it can be aligned with application traces and infrastructure graphs.

Audit the existing configuration and capacity

Capture current values before changing them:

SELECT NOW(6) AS captured_at,
       @@GLOBAL.log_output,
       @@GLOBAL.slow_query_log,
       @@GLOBAL.slow_query_log_file,
       @@GLOBAL.long_query_time,
       @@GLOBAL.min_examined_row_limit,
       @@GLOBAL.log_slow_filter,
       @@GLOBAL.log_slow_verbosity,
       @@GLOBAL.log_slow_rate_limit;

On MariaDB 10.11+, the modern aliases can be queried instead. Save output in the change record so rollback restores the exact previous behavior.

If logging uses FILE, resolve and inspect the actual destination:

mariadb --batch --skip-column-names -e 
  "SELECT @@GLOBAL.slow_query_log_file, @@GLOBAL.datadir;"

Then check the correct path:

namei -l /var/log/mysql/mariadb-slow.log
findmnt -T /var/log/mysql/mariadb-slow.log
df -hT /var/log/mysql
df -i /var/log/mysql

Do not assume a relative filename is relative to the shell directory; MariaDB commonly resolves it under the data directory. Verify permissions, AppArmor or SELinux policy, mount capacity, inode availability, and rotation.

Estimate event volume before lowering the threshold. Performance Schema digest summaries or application tracing can approximate query rate without writing every statement to disk. A five-minute capture at 20,000 statements per second is a different operation from a small internal service.

Choose FILE or TABLE output deliberately

log_output supports FILE, TABLE, FILE,TABLE, and NONE.

FILE output

File output is the normal production choice because it integrates with log rotation and offline tools. It avoids adding diagnostic rows to a table inside the database being diagnosed.

SET GLOBAL log_output = 'FILE';

Advantages:

Straightforward rotation and compression.
Extended slow-log detail is supported.
Analysis can run against a copied file away from production.
Failure is visible through filesystem monitoring.

Risks include disk exhaustion, permissions, sensitive plaintext, and extra writes on the database volume.

TABLE output

TABLE writes into mysql.slow_log, commonly using CSV by default:

SET GLOBAL log_output = 'TABLE';

It permits SQL queries over log entries, but log_slow_verbosity extended output is not supported with TABLE. It also places diagnostic storage and query load inside MariaDB. Access control, growth, backups, and maintenance must be designed explicitly.

Inspect without assuming schema:

SHOW CREATE TABLE mysql.slow_logG
SELECT * FROM mysql.slow_log ORDER BY start_time DESC LIMIT 10;

Do not run expensive grouping scans against a large mysql.slow_log during an incident. Copy data to an analysis system when substantial processing is needed.

NONE and combined output

log_output='NONE' suppresses output even if slow logging is enabled. This is a common explanation for an empty log.

FILE,TABLE duplicates each qualifying event and normally adds cost without diagnostic value. Use it only for a defined reason and bounded window.

Enable a conservative bounded capture

A safe starting window might log statements longer than one second while excluding tiny operations:

SET GLOBAL log_output = 'FILE';
SET GLOBAL long_query_time = 1.000000;
SET GLOBAL min_examined_row_limit = 1000;
SET GLOBAL slow_query_log = ON;

The numbers are examples. Derive thresholds from endpoint budgets and current workload. A 100 ms threshold may be right for an interactive API and reckless for an unfiltered high-throughput capture.

Verify both global state and the file:

SHOW GLOBAL VARIABLES WHERE Variable_name IN (
  'slow_query_log',
  'slow_query_log_file',
  'long_query_time',
  'min_examined_row_limit',
  'log_output'
);

stat /var/log/mysql/mariadb-slow.log
tail -n 40 /var/log/mysql/mariadb-slow.log

Existing sessions may retain session-scoped values after a global change. Global changes supply defaults to new sessions for variables with session scope. Check the actual application connection or recycle its pool deliberately:

SELECT @@SESSION.long_query_time,
       @@SESSION.min_examined_row_limit,
       @@SESSION.log_slow_filter,
       @@SESSION.log_slow_verbosity;

Do not manufacture a costly production query merely to test logging. Use a safe staging statement or wait for a known workload event.

Choose long_query_time from service behavior

long_query_time accepts fractional seconds. Select it by combining:

Server-side latency budget for the endpoint.
Query frequency and expected capture volume.
Current P95/P99 distribution.
Investigation objective and duration.
Storage and log-processing capacity.

Begin high enough to capture clear outliers, analyze them, then lower the threshold in a second bounded window if necessary. Moving directly to zero logs essentially every eligible statement and can cause severe volume and I/O.

A long threshold can miss “death by a thousand cuts.” A 40 ms query executed 50,000 times per minute can consume more resources than a single 10-second report. Use Performance Schema digest totals or application traces to find high aggregate cost; the slow log is strongest at preserving individual examples and extended context.

MariaDB 11.7 adds log_slow_always_query_time, allowing exceptionally long queries to be recorded despite a minimum examined-row filter. Feature-detect it before use:

SHOW GLOBAL VARIABLES LIKE 'log_slow_always_query_time';

Use row limits without hiding critical queries

min_examined_row_limit excludes statements examining fewer than the configured number of rows. It can prevent a high volume of small but slightly slow operations from filling the log.

SET GLOBAL min_examined_row_limit = 10000;

However, a query waiting on storage or a lock may examine few rows and still be critical. A point lookup can also be slow due to networked storage, metadata locks, or overloaded CPU. Pair row filtering with application latency and lock monitoring.

The variable measures rows examined, not table size or rows returned. A query can return one row after examining millions, which is exactly the pattern the filter helps expose.

On MariaDB 10.11+, log_slow_min_examined_row_limit is the preferred name:

SET GLOBAL log_slow_min_examined_row_limit = 10000;

Use the name supported by the release and confirm the effective session value.

Apply log_slow_filter carefully

log_slow_filter can select plan characteristics including:

admin
filesort
filesort_on_disk
filesort_priority_queue
full_join
full_scan
not_using_index
tmp_table
tmp_table_on_disk

Inspect current supported and active values:

SHOW GLOBAL VARIABLES LIKE 'log_slow_filter';

A targeted temporary-table investigation might use:

SET GLOBAL log_slow_filter = 'tmp_table_on_disk,filesort_on_disk';

Filters interact with long_query_time; read the exact version documentation. In particular, not_using_index is logged regardless of long_query_time when enabled. On a busy server, this can record vast numbers of tiny scans and full index scans.

“Not using an index” is not synonymous with “bad query.” A full scan of a 20-row lookup table may be optimal, and a query using an index may still examine most of a large table. Analyze cost and frequency.

Avoid the legacy shortcut:

SET GLOBAL log_queries_not_using_indexes = ON;

unless volume has been estimated and the window is controlled. It maps to the same not_using_index behavior on relevant MariaDB releases.

Add extended verbosity only when needed

MariaDB's log_slow_verbosity can add plan and engine information. Supported values include combinations such as query_plan, explain, innodb, engine, and warnings; exact availability varies by release.

Check the running value:

SHOW GLOBAL VARIABLES LIKE 'log_slow_verbosity';

For a bounded file-based capture on a tested release:

SET GLOBAL log_slow_verbosity = 'query_plan,explain';

Extended output makes each entry larger and may expose more schema or value detail. The All shortcut exists from specified 10.6 maintenance releases, but maximum verbosity should not be the default.

log_slow_verbosity is not supported when log_output='TABLE'. If extended fields are absent, check destination before assuming the variable failed.

EXPLAIN detail in a historical log is helpful, but it does not replace a fresh plan review. Statistics, data distribution, indexes, parameters, and optimizer version may have changed since capture.

Control volume with rate limiting and scope

log_slow_rate_limit can sample eligible statements. Inspect its semantics and supported range on the exact version:

SHOW GLOBAL VARIABLES LIKE 'log_slow_rate_limit';

Sampling reduces volume but can miss rare tenant-specific outliers. Record the sampling configuration with every analysis; counts from a sampled log are not raw execution counts.

Other ways to reduce scope include:

Capture only during the known incident window.
Target a replica or canary with equivalent plans and data.
Set session values on a dedicated diagnostic connection where practical.
Raise the threshold and lower it iteratively.
Use a meaningful minimum examined-row limit.
Select only relevant plan filters.
Exclude statement categories supported by the installed release.

Do not move production reads to a replica for diagnosis without accounting for lag, cache differences, hardware, optimizer settings, and read-after-write semantics.

Persist configuration only after the investigation proves value

For an ongoing production baseline on a supported release:

[mariadb]
log_output = FILE
slow_query_log = ON
slow_query_log_file = /var/log/mysql/mariadb-slow.log
long_query_time = 1
min_examined_row_limit = 1000
log_slow_verbosity = query_plan

Use modern log_slow_* names where the fleet baseline supports them. Verify option-file precedence:

mariadbd --print-defaults
my_print_defaults mariadbd server mysqld

Prepare the directory before restart:

install -d -o mysql -g mysql -m 0750 /var/log/mysql

On SELinux or AppArmor systems, ownership alone may be insufficient. Apply distribution-supported policy, not a blanket security disable.

Dynamic changes can avoid a restart for an investigation. Persist only settings intended to survive reboot and verify them during a planned restart.

Rotate without losing active log writes

Slow logs need size, retention, compression, and deletion policies. Rotation must tell MariaDB to reopen log files after renaming them.

Inspect distribution-provided configuration first:

rg -n 'mariadb|mysql|slow' /etc/logrotate.d /etc/logrotate.conf

A conceptual logrotate policy is:

/var/log/mysql/mariadb-slow.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0640 mysql adm
    sharedscripts
    postrotate
        /usr/bin/mariadb-admin --defaults-file=/secure/path flush-logs
    endscript
}

Do not deploy that block unchanged. Credential handling, group names, executable paths, systemd integration, and packaged rotation hooks differ. Avoid placing passwords on the command line, where process listings or shell history may expose them.

Test configuration syntax and forced rotation in staging:

logrotate --debug /etc/logrotate.conf

After rotation, confirm MariaDB writes to the new inode, disk usage declines as expected, ownership is correct, and no deleted-but-open large file remains:

lsof +L1 2>/dev/null | rg 'mariadbd|mariadb-slow'

Never truncate the active log casually during an incident. Preserve the evidence and rotate through the supported procedure.

Protect credentials and personal data

SQL text may contain:

Email addresses, names, tokens, and session identifiers.
Literal passwords from unsafe application code.
Financial, health, or tenant-specific values.
Internal table names and business logic.
Hostnames, usernames, and source addresses.

Treat slow logs as production data. Restrict filesystem access, encrypt the volume where required, use secure transfer, define retention, audit access, and sanitize samples before tickets or chat messages.

Do not collect the general query log as a substitute. It records far more statements and can expose even more sensitive data with much higher volume.

Prefer parameterized application SQL, but do not assume server logs always preserve placeholders rather than expanded values. Test the driver and server behavior.

Copy a stable analysis artifact

Analyze a rotated or safely copied file so results do not change underneath the tool:

install -d -m 0750 /var/lib/db-diagnostics/case-2026-08-25
cp --preserve=mode,timestamps 
  /var/log/mysql/mariadb-slow.log.1 
  /var/lib/db-diagnostics/case-2026-08-25/
sha256sum /var/lib/db-diagnostics/case-2026-08-25/mariadb-slow.log.1

The diagnostic directory must have appropriate ownership and encryption. A checksum establishes which artifact produced the report; it is not proof the log is complete.

Record server identity, UTC start/end, time zone, configuration, rotation events, and sampling rate alongside it. Without these, cross-host timestamps and counts are easy to misinterpret.

Aggregate query shapes with mariadb-dumpslow

mariadb-dumpslow groups similar SQL by abstracting literal values. Confirm options on the installed client:

mariadb-dumpslow --help

Common analyses include:

mariadb-dumpslow -s t -t 20 
  /var/lib/db-diagnostics/case-2026-08-25/mariadb-slow.log.1

mariadb-dumpslow -s c -t 20 
  /var/lib/db-diagnostics/case-2026-08-25/mariadb-slow.log.1

mariadb-dumpslow -s r -t 20 
  /var/lib/db-diagnostics/case-2026-08-25/mariadb-slow.log.1

Depending on utility version, these sort by time, count, or row-related metrics. Verify the help text rather than memorizing flags from another distribution.

Run several rankings:

Highest total time.
Highest average time.
Most executions.
Most rows examined.
Largest rows-examined-to-rows-sent disparity.

One top-20 report is not a diagnosis. A high-frequency medium-cost digest can dominate total database time while never ranking first by maximum latency.

Third-party analyzers can provide percentiles and richer fingerprints, but they handle sensitive SQL. Validate provenance, parser compatibility, data destination, and licensing before use.

Turn a log entry into a reproducible case

For each candidate, capture:

Normalized query shape or digest.
Execution count in the observed window.
Total and percentile latency if available.
Rows examined and rows sent.
Schema, host role, and application endpoint.
Representative parameter classes, including skewed tenants.
Temporary-table, filesort, full-scan, and warning indicators.
Concurrency and storage state at the same timestamp.

Do not paste a production DELETE, UPDATE, or INSERT from the log into a console. Reproduce on an isolated restored dataset or convert it carefully to a read-only inspection when semantically possible.

Sanitize literals while preserving selectivity. Replacing a high-volume tenant ID with a random low-volume ID can make the problem disappear and lead to the wrong plan conclusion.

Use EXPLAIN and ANALYZE safely

Start with plain EXPLAIN, which does not execute a normal SELECT:

EXPLAIN
SELECT id, created_at, total_amount
FROM sales.orders
WHERE customer_id = 481
  AND status = 'paid'
ORDER BY created_at DESC
LIMIT 100;

Inspect selected keys, access type, estimated rows, filtering, join order, Using temporary, and Using filesort. Then compare existing indexes:

SHOW INDEX FROM sales.orders;

ANALYZE FORMAT=JSON executes the statement and returns observed execution data. Use it only for a proven read-only query in a safe environment or controlled production window:

ANALYZE FORMAT=JSON
SELECT id, created_at, total_amount
FROM sales.orders
WHERE customer_id = 481
  AND status = 'paid'
ORDER BY created_at DESC
LIMIT 100;

Do not run ANALYZE on an unbounded expensive query merely because it came from the slow log. Do not assume syntax and side effects for DML match SELECT; verify version documentation.

Plans are hypotheses. Test representative data distribution and concurrency, because an index beneficial for one tenant can be poor for another.

Fix root causes, not only logged symptoms

Common corrections include:

Rewrite non-sargable predicates into indexed ranges.
Add a composite index matching equality, range, and ordering needs.
Remove unused selected payload columns before sorting or grouping.
Replace large OFFSET pagination with stable keyset pagination.
Eliminate N+1 application queries or cache a safe repeated lookup.
Update optimizer statistics through a controlled procedure.
Break permissible bulk work into restartable batches.
Shorten transactions that hold locks while doing external work.
Schedule reports away from write peaks or isolate them safely.
Correct data-type, collation, or implicit-conversion mismatches.

Do not add every index suggested by a log entry. Each index consumes disk, buffer pool, redo, backup time, and write throughput. Review workload-wide overlap and redundancy.

Configuration tuning may be justified, but increasing buffers does not repair a query that reads 100 times more rows than necessary. Preserve before/after evidence so improvements are attributable.

Verify a fix with comparable evidence

Compare the same query family before and after under similar:

Parameter selectivity.
Dataset size and statistics.
Concurrency and traffic mix.
Cache state.
Server configuration and hardware.
Capture threshold, filter, verbosity, and sampling.

Success metrics should include:

Total database time consumed by the digest.
Execution count and latency percentiles.
Rows examined and returned.
Temporary tables and disk spills.
Sort work and merge passes.
CPU, storage latency, and memory.
Write overhead from any new index.
Replica lag and application error rate.

A query disappearing from the slow log is weak evidence if the threshold changed. It may now take 990 ms under a 1-second threshold while still violating a 500 ms endpoint budget. Measure directly.

Disable and restore the diagnostic window

At the planned end time, restore every changed value. If logging was previously disabled:

SET GLOBAL slow_query_log = OFF;

Restore the captured values for:

log_output
long_query_time
min_examined_row_limit
log_slow_filter
log_slow_verbosity
log_slow_rate_limit
slow_query_log

Verify the result rather than trusting successful SET responses:

SHOW GLOBAL VARIABLES WHERE Variable_name IN (
  'slow_query_log',
  'long_query_time',
  'min_examined_row_limit',
  'log_output',
  'log_slow_filter',
  'log_slow_verbosity',
  'log_slow_rate_limit'
);

Existing sessions may retain session settings. If a persistent configuration file was changed, revert it through the normal deployment mechanism and verify parsed options.

Archive only the approved artifact, apply retention, and remove temporary copies through the organization's secure-data process.

Troubleshoot common slow-log failures

Logging is ON but the file is empty

Check log_output; NONE suppresses writes. Verify threshold, row limit, filters, actual path, permissions, free disk, mandatory access control, and whether tested sessions inherited current values.

SHOW GLOBAL VARIABLES WHERE Variable_name IN (
  'slow_query_log','slow_query_log_file','long_query_time',
  'min_examined_row_limit','log_output','log_slow_filter'
);

Review the MariaDB error log for file-open failures.

The log grows unexpectedly fast

Check whether not_using_index or log_queries_not_using_indexes is active. Inspect threshold, rate limit, traffic change, and duplicated FILE,TABLE output. Raise the threshold or disable the capture according to the preplanned abort criteria; do not wait for disk exhaustion.

Rows examined are huge but query time is low

Warm cache and fast storage may mask inefficient work. Multiply rows by execution frequency, then review plan and indexes. The same query can become critical as data or concurrency grows.

Query time is high but rows examined are low

Investigate lock waits, metadata locks, storage latency, CPU scheduling, result size, functions, network dependencies in plugins, and resource contention. A missing index is only one possible cause.

The slow log does not match application latency

Application latency can include pool wait, connection setup, network travel, proxy queues, result transfer, ORM materialization, and client processing. Correlate a trace ID or timestamp across layers rather than forcing one metric to explain the full request.

mariadb-dumpslow fails to parse entries

Confirm client/server format compatibility, uncompressed input, complete rotation boundaries, and extended fields. Preserve the original artifact, use the client tool matching the server family, and validate counts against raw entries.

Rotation succeeded but disk space did not return

The process may still hold a deleted file open. Check lsof +L1, then issue the distribution-supported log reopen or flush action. Do not restart the database solely to reclaim a log until the safer reopen procedure is tested.

Production monitoring and operating checklist

Monitor:

Slow-query count rate.
Slow-log bytes written per minute.
Filesystem free bytes and inodes.
Rotation success and oldest retained file.
MariaDB log-open errors.
Query latency and total time by digest.
Rows examined per digest and per returned row.
Temporary-table and filesort rates.
CPU, I/O latency, Threads_running, and replica lag.

Operational checklist:

Define question, owner, start time, end time, and abort thresholds.
Record version and all relevant global values.
Estimate capture volume.
Prefer FILE with tested rotation for extended analysis.
Begin with a conservative time threshold.
Use not_using_index only in a tightly controlled window.
Protect logs as sensitive production data.
Analyze a stable copied or rotated artifact.
Rank by total cost, count, latency, and rows.
Validate candidates with plans and realistic parameters.
Measure write-side cost of new indexes.
Restore settings and verify rollback.
Retain evidence only as long as policy requires.

FAQ

How do I enable the MariaDB slow query log?

Set log_output to a real destination, choose long_query_time and row filters, then set slow_query_log=ON or log_slow_query=ON on MariaDB 10.11+. Verify the effective file and session values.

Can I enable it without restarting MariaDB?

Yes, the main logging, threshold, filter, and verbosity variables are dynamic on common MariaDB releases. Persist only the settings intended to survive restart.

What is a good long_query_time value?

There is no universal value. Start from the service's server-side latency budget, query rate, storage capacity, and diagnostic question. Lower it incrementally in bounded windows.

Does log_queries_not_using_indexes find every bad query?

No. Full scans of small tables can be optimal, and inefficient queries can use an index. The option can also generate enormous logs because qualifying statements may ignore the time threshold.

Is TABLE output better for analysis?

Usually not in production. It enables SQL access but lacks log_slow_verbosity support and adds diagnostic storage inside MariaDB. FILE output with secure offline analysis is generally more flexible.

Does the log show currently running queries?

No. Entries are written after qualifying statements finish. Use process-list, Performance Schema, tracing, and monitoring for active work.

Can slow logs contain passwords or personal data?

Yes. SQL literals and connection context may expose sensitive information. Restrict access, encrypt and retain appropriately, and sanitize anything shared outside the incident team.

How do I prove a query optimization worked?

Compare the same digest, parameters, concurrency, and capture settings. Measure total time, percentiles, rows examined, plan, temp/sort work, system resources, and write overhead.

Conclusion

The MariaDB slow query log turns performance complaints into evidence only when its scope is deliberate. Define a diagnostic question, capture the running configuration, choose conservative thresholds and filters, protect the destination, and stop at a planned time. Version-aware names and extended statistics matter, but more detail is valuable only when volume remains controlled.

Analysis should move from individual entries to normalized query families, total workload cost, representative parameters, and execution plans. Fix the query, index, transaction, or workload root cause, then repeat a comparable measurement and restore diagnostic settings. That closed loop is what makes the slow query log an engineering tool rather than an ever-growing archive of symptoms.