sql - 对 Rails/Heroku 上的 Postgres 数据库的意外 SQL 查询

Question

我使用 NewRelic 深入研究了对我的一个 Rails 应用程序的一个非常长的请求，发现许多看起来完全陌生的 SQL 查询占用了很长的时间。我用谷歌搜索了一下，但对于它们是什么一无所知，更不用说我是否可以阻止它们的发生了。

SELECT COUNT(*) FROM pg_class c LEFT JOIN pg_namespace n ON n.oid = c.relnamespace WHERE c.relkind in (?, ?) AND c.relname = ? AND n.nspname = ANY (current_schemas(false))

……和……

SELECT a.attname, format_type(a.atttypid, a.atttypmod), pg_get_expr(d.adbin, d.adrelid), a.attnotnull, a.atttypid, a.atttypmod FROM pg_attribute a LEFT JOIN pg_attrdef d ON a.attrelid = d.adrelid AND a.attnum = d.adnum WHERE a.attrelid = ?::regclass AND a.attnum > ? AND NOT a.attisdropped ORDER BY a.attnum

…每次发生 7 次，总共耗时 145 毫秒和 135 毫秒(分别)。

SELECT DISTINCT(attr.attname) FROM pg_attribute attr INNER JOIN pg_depend dep ON attr.attrelid = dep.refobjid AND attr.attnum = dep.refobjsubid INNER JOIN pg_constraint cons ON attr.attrelid = cons.conrelid AND attr.attnum = cons.conkey[?] WHERE cons.contype = ? AND dep.refobjid = ?::regclass

...以 104ms 的成本执行了 2 次，并且...

SHOW search_path

…在一次通话中要求 45 毫秒。

我的直觉说这些与 Postgres Rails 适配器有关，但我不明白是什么触发了它们或它们在做什么，或者(更重要的是)它们为什么在典型请求期间触发。

---

我刚刚更彻底地检查了日志，看起来这个请求运行的 Dyno 已经在几秒钟前转换为“up”，所以这个请求很可能是第一个。

Answer 1

表 pg_class、pg_attribute、pg_depend 等都描述了 postgres 中的表、列和依赖项。在 Rails 中，模型类由表定义，因此 Rails 读取表和列来找出每个模型的属性。

在开发模式下，它会在每次访问模型时查找这些值，因此如果您最近进行了更改，Rails 会知道。在生产模式下，Rails 会缓存它，这样您就不会那么频繁地看到它们，所以这真的不是问题。