MiniProfiler 列出的额外查询

Question

在我的控制器操作中，我included 视图所需的所有关联，以避免多次调用数据库。 （我试图隔离视图层以仅呈现控制器收集的数据）。

---

我发现视图仍然与数据库通信（17 个查询）：

---

这些 17 extra queries 不是必需的。由于我已经从控制台测试了控制器查询，并且它成功收集了部分 _dropdown（在 5 个查询 中）所需的所有数据，而无需任何进一步的数据库通信。

这是我的控制器中的query，它意味着避免N+1的问题。 （包括视图中调用的所有变量）

---

这里是下拉代码：

- @messages.each do |message|
    %li.conversation-container
        %a{href: conversation_path(message.conversation_id)}
            - if message.sender != current_user 
                .notification-avatar{style: "background: url(#{message.sender.avatar_url}); background-size: contain; background-repeat: no-repeat; background-position: 50% 50%;"}
            - else
                - other_participant = message.conversation.conversation_participants.select{|p| p.user_id != current_user.id }.first.user 
                .notification-avatar{style: "background: url(#{other_participant.avatar_url}); background-size: contain; background-repeat: no-repeat; background-position: 50% 50%;"}
            %p
                %strong
                    - if message.sender != current_user 
                        = message.sender.name
                    - else
                        = other_participant.name
                %br
                - if message.sender == current_user
                    %i.fa.fa-mail-reply-all
                = truncate(message.body,length: 25)

                .time
                    = time_ago_in_words(message.created_at)
                    ago
- if @messages.count == 0
    %li
        .empty-state-text-white
            No messages

---

控制台输出：

2.0.0-p353 :006 > ms = Message.dropdown_for(3).all
  Message Load (1.2ms)  SELECT "messages".* FROM "messages" LEFT JOIN messages AS m ON messages.id != m.id 
 AND m.conversation_id = messages.conversation_id 
 AND messages.created_at < m.created_at INNER JOIN conversation_participants AS cp ON cp.conversation_id = messages.conversation_id AND cp.user_id = 3 WHERE (m.id IS NULL) ORDER BY cp.seen , cp.updated_at DESC LIMIT 5
  User Load (0.7ms)  SELECT "users".* FROM "users" WHERE "users"."id" IN (6, 4, 5)
  Conversation Load (0.4ms)  SELECT "conversations".* FROM "conversations" WHERE "conversations"."id" IN (4, 2, 3)
  ConversationParticipant Load (0.2ms)  SELECT "conversation_participants".* FROM "conversation_participants" WHERE "conversation_participants"."conversation_id" IN (4, 2, 3)
  User Load (0.6ms)  SELECT "users".* FROM "users" WHERE "users"."id" IN (6, 3, 4, 5)
 => [#<Message id: 8, body: "saSasa", sender_id: 6, conversation_id: 4, sent: true, attachment_id: nil, attachment_type: nil, created_at: "2014-11-17 16:05:40", updated_at: "2014-11-17 16:05:40">, #<Message id: 2, body: "asdnas dagsdashjdg jahs d", sender_id: 4, conversation_id: 2, sent: true, attachment_id: nil, attachment_type: nil, created_at: "2014-11-17 11:32:36", updated_at: "2014-11-17 11:32:36">, #<Message id: 6, body: "SADASD A DSA ", sender_id: 5, conversation_id: 3, sent: true, attachment_id: nil, attachment_type: nil, created_at: "2014-11-17 13:43:34", updated_at: "2014-11-17 13:43:34">] 

2.0.0-p353 :007 > ms.first.conversation.conversation_participants.select{|cp| cp.user_id != 3}.first.user
 => #<User id: 6, first_name: "Ddsfsd", middle_name: nil, last_name: "Fsdfsd", photo: nil, email: "1@k.com", encrypted_password: "$2a$10$5sGIb2DbQ1ctMrTzD3AJ0uV18hhiC5Ei1wcfE7MSAvRU...", reset_password_token: nil, reset_password_sent_at: nil, remember_created_at: nil, sign_in_count: 1, current_sign_in_at: "2014-11-17 15:27:06", last_sign_in_at: "2014-11-17 15:27:06", current_sign_in_ip: "127.0.0.1", last_sign_in_ip: "127.0.0.1", confirmation_token: nil, confirmed_at: "2014-11-17 15:27:48", confirmation_sent_at: "2014-11-17 15:27:05", unconfirmed_email: nil, failed_attempts: 0, unlock_token: nil, locked_at: nil, authentication_token: nil, created_at: "2014-11-17 15:27:05", updated_at: "2014-11-17 15:27:48", slug: "ddsfsd_fsdfsd"> 

2.0.0-p353 :008 > ms.count
 => 3 

---

如何阻止这些查询无目的运行？

Answer 1

* 调试

在调试可能导致此问题的所有可能因素之后。 我试图在我的development.rb 中将config.cache_classes 设置为true。这成功删除了所有额外的查询。

我的结论是（默认情况下）当没有缓存类时，不会为任何模型加载架构。换句话说，当 config.cache_classes 设置为 false 时，每个模型的架构都会作为单独的查询为每个请求加载。

这是一个类似的问题column_definitions method being called before and after every single SQL statement on PostgreSQL。

* 结论

cache_classes 应在 development 环境中设置为 false。 忽略来自 postgresql 连接适配器的额外内部查询 为每个模型加载架构，因为它不会影响您的 生产环境（生产有 config.cache_classes 设置为 true)。

Answer 2

你可以试试子弹 gem，它会告诉你查询中是否有任何 N+1 问题。如果没有 N+1 问题，那么你应该尝试实现片段缓存。

Answer 3

简单的问题。您是否尝试在方法调用的末尾放置一个 .to_a ？ 喜欢@messages.to_a？

Answer 4

我会检查日志以查看这 17 个查询是什么，或者单击 17 sql 链接可能会显示这些查询。从那里，您可能会看到您忘记了 includes 导致 N+1 问题的表。

编辑：

如this site 的“延迟加载”部分所述，您可以在控制器操作中将.all 添加到查询的末尾以触发其执行，并防止查询在您的视图中延迟执行。正如我在评论中提到的，Rails 范围允许您构建查询并在使用它们时执行。要执行，您可以调用 .all、.count、.each 或 .first。在 Rails 4 中，您可以使用.load 在控制器中执行查询。

Answer 5

这可能是所谓的“N + 1”问题，它是由于延迟加载而发生的。如果没有应用程序日志，我不能肯定地说。您可以按照here 的描述使用急切加载。

Answer 6

您的查询表述不当。您应该使用包含或连接。

将您的查询分为以下两部分：

message_ids = Message.joins("LEFT JOIN messages AS m ON messages.id != m.id 
          AND m.conversation_id = messages.conversation_id 
          AND messages.created_at < m.created_at")
   .where('m.id IS NULL')
   .joins("INNER JOIN conversation_participants AS cp 
          ON cp.conversation_id = messages.conversation_id 
          AND cp.user_id = #{user_id}")
   .order("cp.seen, cp.updated_at DESC")
   .limit(5).map(&:id)

messages = Message.includes(:sender).
    includes(conversation: [{conversation_participants: :user}]).
    where(id: message_ids)