MySQL Slow Query Logging Disabled on GCP Cloud SQL

When a database starts dragging, the first question everyone asks is "which query is slow?" If you do not have slow query logging on, you are guessing. This Lensix check looks at your GCP Cloud SQL for MySQL instances and reports any that are running without slow query logging configured.

It is a small flag with an outsized impact on both performance debugging and security visibility. Let's walk through what it catches and how to put it right.

---

What this check detects

The sql_mysqlslowquery check inspects the database flags on each Cloud SQL MySQL instance in your project. It fails when the instance does not have the slow_query_log flag set to on.

MySQL's slow query log records queries that take longer than a configurable threshold (long_query_time, in seconds) to execute. On Cloud SQL, when you enable the flag, those entries are captured and surfaced through Cloud Logging rather than written to a local file you have to SSH in and read.

---

Why it matters

Slow query logging sits at the intersection of performance and security, which is exactly why it is worth flagging.

Performance and reliability

Without slow query data, you cannot answer basic operational questions during an incident. A single unindexed query running across millions of rows can saturate CPU, exhaust connections, and stall the rest of the application. When that happens at 2am, the slow query log is the fastest path from "the app is down" to "this specific query is the culprit." Without it, you are reduced to reproducing the issue or staring at aggregate CPU graphs.

Security visibility

Slow query logs are also a security signal. Several attack patterns show up as unusually slow or unusual queries:

• SQL injection probes often generate heavy, malformed, or expensive queries as an attacker enumerates your schema.
• Data exfiltration via bulk SELECT statements pulling entire tables tends to run long enough to land in the slow log.
• Denial of service through deliberately expensive queries (cartesian joins, full table scans) is exactly the kind of activity the log captures.

If you ever have to reconstruct what an attacker did inside your database, query logs are one of the few artifacts that can tell you. No log, no forensic trail.

Compliance

Frameworks like CIS GCP Foundations and SOC 2 expect logging to be enabled on database tiers. An instance with no query logging is a common, easily avoided audit finding.

---

How to fix it

The fix is to set two database flags: slow_query_log to enable capture, and long_query_time to control the threshold. Below are the gcloud, Console, and IaC approaches.

Option 1: gcloud CLI

Set both flags in a single patch. Note that gcloud's --database-flags replaces the entire flag set, so include any flags you already have.

gcloud sql instances patch INSTANCE_NAME \
  --project=PROJECT_ID \
  --database-flags=slow_query_log=on,long_query_time=2

Here long_query_time=2 logs any query taking two seconds or longer. Tune this to your workload (more on thresholds below).

Confirm the change applied:

gcloud sql instances describe INSTANCE_NAME \
  --format="value(settings.databaseFlags)"

Option 2: Google Cloud Console

1. Open SQL in the Cloud Console and select your MySQL instance.
2. Click Edit.
3. Expand Flags (under "Customize your instance").
4. Click Add a database flag, choose slow_query_log, and set it to on.
5. Add a second flag, long_query_time, and set a threshold such as 2.
6. Click Done, then Save.

Option 3: Terraform

If you manage Cloud SQL as code, declare the flags directly on the instance resource so they are enforced on every apply.

resource "google_sql_database_instance" "mysql" {
  name             = "my-mysql-instance"
  database_version = "MYSQL_8_0"
  region           = "us-central1"

  settings {
    tier = "db-custom-2-7680"

    database_flags {
      name  = "slow_query_log"
      value = "on"
    }

    database_flags {
      name  = "long_query_time"
      value = "2"
    }
  }
}

Reading the logs

Once enabled, view slow queries in Logs Explorer:

gcloud logging read \
  'resource.type="cloudsql_database" AND logName:"mysql-slow.log"' \
  --project=PROJECT_ID \
  --limit=20 \
  --format=json

---

How to prevent it from happening again

Toggling a flag on one instance is easy. Making sure it stays on across every instance someone spins up next quarter is the real work. A few approaches stack well together.

Enforce it in IaC and gate it in CI

If every Cloud SQL instance is created through Terraform, you can block any module that does not set the flag. Using Conftest with an OPA Rego policy in your pipeline:

conftest test plan.json --policy policy/

A policy that fails the plan when a MySQL instance lacks slow query logging:

package main

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "google_sql_database_instance"
  contains(resource.change.after.database_version, "MYSQL")

  flags := { f.name | f := resource.change.after.settings[_].database_flags[_] }
  not flags["slow_query_log"]

  msg := sprintf("Cloud SQL MySQL instance '%s' must set slow_query_log", [resource.change.after.name])
}

Use Organization Policy and Security Command Center

For drift that happens outside your pipeline (manual console changes, for example), lean on detection. Security Command Center surfaces logging misconfigurations, and Lensix runs this exact check continuously so an instance that loses the flag does not stay silent for long.

---

Best practices

• Set a sensible threshold. A long_query_time of 0 logs everything and will flood your logs and your bill. Start at 2 seconds for most OLTP workloads, then tighten toward 1 or 0.5 once you have cleaned up the obvious offenders.
• Watch your log volume and cost. Slow query logs flow through Cloud Logging, which is billed on ingestion. A misconfigured threshold on a busy instance can generate a surprising amount of data. Set log-based metrics and budget alerts.
• Route logs out for retention. Export slow query logs to BigQuery or a sink for long-term analysis and incident forensics, since Cloud Logging's default retention may be shorter than your compliance requirements.
• Pair with general query insights. Cloud SQL Query Insights gives you aggregated, low-overhead performance data that complements the raw slow log. Use Insights for trends and the slow log for specific offenders.
• Apply the same standard everywhere. Slow query logging belongs on dev and staging too. Catching an expensive query before it ships is the whole point.

Enabling the slow query log costs almost nothing and gives you both a performance debugger and a security signal in one flag. Turn it on, set a threshold that fits your workload, and enforce it in code so it never quietly disappears.