Cloud SQL for MySQL instances without the slow_query_log flag turned on

Why MySQL needs the slow log to explain latency

MySQL writes a statement to the slow query log when it runs longer than long_query_time. With the slow_query_log flag off, that record never exists. When a page gets slow or CPU climbs, there is no list of the statements responsible, and teams end up guessing, adding indexes blind, or scaling the instance up to cover a single bad query.

Cloud SQL makes the flag slightly less obvious than stock MySQL. The database flags reference says that to make slow query logs available in Logs Explorer you must set both slow_query_log to on and log_output to FILE. The TABLE output is not recommended because the table can grow large enough to slow restarts and cost the instance its SLA coverage. Logs on the instance disk rotate after 24 hours or 100 MB, and Cloud Logging charges apply to what is exported.

Reading the flags on each MySQL instance

gcloud sql instances list \
  --filter="databaseVersion:MYSQL*" \
  --format="table(name, databaseVersion, settings.databaseFlags)"

Look for slow_query_log with value off, and for log_output. An instance with no slow_query_log entry is running with the default, which is off, so ZopNight flags it too.

What must be true before it fires

1. The instance engine is MySQL. The slow query log is a MySQL flag, so PostgreSQL and SQL Server instances are outside this rule entirely.
2. ZopNight’s reading of the instance’s database flags does not show slow_query_log set to on. An explicit off and a missing entry are treated the same way.

That is the whole check. No metric, query count or time window is involved.

When nothing is reported

Any slow_query_log value other than on, including a missing entry, counts as off. Only an instance whose settings were not collected at all is skipped. Instances with the slow log on are silent even if log_output is set to NONE, which Google notes makes the logs inaccessible, so check that flag yourself when you enable logging.

Operational risk rather than a saving

There is no saving attached. Turning the log on adds a small amount of Cloud Logging volume if you export it. The value is diagnostic: when latency spikes you have the statements, their duration and the rows examined instead of a CPU graph and a hunch.

Enabling slow query logging safely

1. List the flags already set on the instance. The flag configuration steps warn that --database-flags overwrites every flag previously set; anything you leave out returns to its default.

2. Apply the full set, including the existing flags plus the logging ones:

   gcloud sql instances patch INSTANCE_NAME \
     --database-flags=EXISTING_FLAG=VALUE,slow_query_log=on,log_output=FILE,long_query_time=2

3. Pick a long_query_time that suits the workload; Cloud SQL allows values below 1 second.

4. Confirm entries appear in Logs Explorer, then set up a log-based metric or alert on the volume.