GCP CloudSQL MySQL慢查询配置异常求助：日志记录不符合规则

可能的原因及解决办法 #

• log_queries_not_using_indexes参数默认开启
  这是最常见的问题：CloudSQL的MySQL默认可能开启了log_queries_not_using_indexes=ON，该参数会把所有未使用索引的查询都记录到慢日志中，不管执行时间是否超过long_query_time。这会导致大量执行时间小于3秒的查询被误记，真正的慢查询反而可能被淹没。
  验证方法：登录MySQL实例执行 SHOW GLOBAL VARIABLES LIKE 'log_queries_not_using_indexes';，如果返回ON，可根据需求将其设为OFF（通过CloudSQL控制台或执行 SET GLOBAL log_queries_not_using_indexes=OFF;），或者在Log Explorer中过滤掉这类日志。

• 参数未真正生效
  即使在CloudSQL控制台配置了long_query_time=3，也可能因以下情况未生效：

  • 配置未应用：修改参数后需点击「应用配置」，long_query_time属于动态参数一般无需重启，但需确认全局变量是否更新；
  • 会话级参数覆盖：个别客户端会话可能单独设置了long_query_time（比如 SET SESSION long_query_time=0.5;），导致该会话的查询按会话级参数记录。
    验证方法：执行 SHOW GLOBAL VARIABLES LIKE 'long_query_time'; 确认全局值为3，再执行 SHOW VARIABLES LIKE 'long_query_time'; 检查当前会话参数是否一致。

• 日志时间字段误解
  慢日志中的Query_time是查询实际执行时间，但如果存在较长锁等待时间（Lock_time），可能会让你误以为短时间查询被记录；或者你混淆了Lock_time和Query_time字段，误判了触发条件。
  解决方法：查看日志完整内容，确认触发慢日志的时间字段是Query_time，同时检查日志中是否有未使用索引的备注，判断是否因索引问题触发记录。

• Log Explorer过滤逻辑错误
  若找不到符合要求的慢查询，大概率是过滤条件写错了：
  CloudSQL的慢日志在Log Explorer中嵌套在jsonPayload下，正确的过滤条件应为 jsonPayload.query_time >= 3，而非直接写query_time >=3；如果开启了log_queries_not_using_indexes，还可以添加NOT jsonPayload.message: "Using index"来筛选真正的慢查询。

内容的提问来源于stack exchange，提问作者Tetsuya Saitou