Cloud SQL MySQL instances with slow_query_log off

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

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.