# Cloud SQL Slow Query Log Disabled

> Cloud SQL MySQL instances with the database flag slow_query_log absent or off get flagged by ZopNight rule RC-1242. The discoverer reads the instance's databaseFlags and records an explicit false; Postgres and SQL Server instances are skipped because the flag only exists on MySQL. Severity is low and the saving is $0.

Source: https://zop.dev/integrations/gcp/recommendations/cloud-sql-slow-query-log-disabled
Updated: 2026-08-19

---

## One MySQL flag, and what its absence hides

Without `slow_query_log`, a Cloud SQL MySQL instance has no record of which queries are
slow. The symptom arrives anyway (page loads degrade, a batch job overruns), but the
evidence does not exist, so the investigation starts from zero: enable the log, wait for the
problem to recur, then diagnose. The flag exists precisely so the evidence is already there
the first time. ZopNight rates the gap low severity with no dollar figure attached; the cost
is diagnostic time during an incident, which no rule can price.

## Why Postgres and SQL Server are never flagged

`slow_query_log` is a MySQL-only database flag. PostgreSQL expresses the same idea through
`log_min_duration_statement`, and SQL Server has its own tooling; on those engines the MySQL
flag is meaningless and cannot even be set. The rule therefore gates on the engine the
discoverer derives from the instance's `databaseVersion` and evaluates only when it is
`mysql`. An absent or unknown engine also abstains: the rule would rather stay silent than
lecture a Postgres instance about a MySQL flag.

## Explicit false, not missing data

Detection here is proven, not guessed. During discovery ZopNight walks the instance's
`settings.databaseFlags` list: the marker defaults to false and flips to true only when a
flag named `slow_query_log` carries the value `on`. Because both polarities are always
written for MySQL instances, the rule fires solely on an explicit false. An instance whose
flags were never parsed produces no finding. The read path is `cloudsql.instances.list`
under `roles/cloudsql.viewer`, alongside bulk discovery under `roles/cloudasset.viewer`;
nothing is written back.

## Verify the flag with gcloud

```bash
gcloud sql instances describe INSTANCE_NAME \
  --format="flattened(settings.databaseFlags[])"
```

Look for a `slow_query_log` entry with value `on`. No entry at all means the engine default
applies, which for MySQL is off.

## Turning it on without drowning in logs

Set `slow_query_log=on` together with a sane `long_query_time` (1 second is the usual
starting point), so the log captures genuinely slow statements rather than everything. Add
`log_output=FILE` so entries land in Cloud Logging where they can be queried and retained.
Flag changes on Cloud SQL apply without a restart for these particular flags, so the edit is
safe to make on a live instance; the finding clears on the next discovery pass once the flag
reads `on`.