Google Cloud SQL中information_schema重复慢查询的触发原因及禁用方法

先给你拆解下这个问题的可能原因，再说说对应的处理思路——我在处理Cloud SQL相关问题时碰到过不少类似的情况：

一、谁在触发这个查询？ #

这个查询是在统计数据库里不同存储引擎的表数量，大概率是以下几种情况之一：

• Cloud SQL自身的运维/监控进程：Google Cloud SQL会定期收集实例的元数据，包括存储引擎分布这类信息，用来做健康检查、资源调度或者监控面板的数据展示。4-5秒的间隔也和Cloud SQL部分监控指标的采样周期匹配，这是最常见的原因。
• 第三方监控/管理工具：如果你自己挂载了Prometheus、Zabbix这类监控工具，或者用了phpMyAdmin、DataGrip这类数据库管理工具的自动刷新功能，它们经常会定期查询information_schema来获取数据库状态，这类工具很容易触发这个查询。
• 自定义应用/脚本：检查下你的业务应用里有没有定时任务，或者用的ORM框架是不是自动加载了元数据？有些框架会定期拉取表结构信息，不小心就会衍生出这类统计查询。

二、能不能禁用？该怎么处理？ #

如果是Cloud SQL自身触发的 #

这个基本没法直接禁用，因为是Google维护实例的必要操作，但可以优化它的耗时，避免出现在慢日志里：

• 升级实例配置：查询耗时10秒说明information_schema的访问效率极低，大概率是实例内存不足（information_schema的查询依赖内存缓存），或者磁盘IO性能跟不上。可以考虑给Cloud SQL实例加内存，或者把磁盘换成更高性能的SSD类型。
• 调整元数据缓存时长：MySQL有个information_schema_stats_expiry参数，默认是24小时的缓存有效期，但如果你的表结构变化不频繁，可以把这个值调小（比如设为3600秒），让元数据缓存更久，减少查询的触发频率。你可以在Cloud SQL的实例参数配置里找到这个参数进行修改。

如果是第三方工具/自定义应用触发的 #

• 排查监控工具配置：找到对应的监控工具，看看有没有自动刷新数据库状态的选项，把刷新频率调低，或者直接关闭不必要的元数据收集功能。
• 检查应用代码：搜一搜业务代码里有没有这个查询，或者看看ORM的配置，是不是开启了自动元数据刷新？如果有的话，要么关闭这个功能，要么改成按需加载。
• 定位触发源：可以开启Cloud SQL的通用查询日志（general log），里面会记录执行这个查询的连接信息（比如来源IP、登录用户），这样就能精准定位到底是谁在触发这个查询。

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