Rails%203%20In%20Action

446 CHAPTER 16 Basic performance enhancements
This line would generate an SQL query like this:
SELECT "tickets".* FROM "tickets"
INNER JOIN "tags_tickets" ON "tags_tickets"."ticket_id" = "tickets"."id"
INNER JOIN "tags" ON "tags"."id" = "tags_tickets"."tag_id"
WHERE ("tickets".project_id = 1)
The INNER JOIN parts of the query here mean that it will find all records in the
tickets table that have tags only. It will also return a ticket record for every tag that it
has, so if one ticket has three tags it will return three tickets. This is somewhat of a
problem, given that you’re going to want to display all tickets regardless of if they are
tagged or not, and you definitely don’t want three of them appearing when only one
should.
To fix this, use join’s brother includes, switching the line in the show action to
this:
@tickets = @project.tickets.includes(:tags).page(params[:page])
When you refresh the page, Rails will generate two queries this time around:
SELECT "tickets".* FROM "tickets"
WHERE ("tickets".project_id = 1)
LIMIT 50
OFFSET 0
SELECT "tags".*, t0.ticket_id as the_parent_record_id FROM "tags"
INNER JOIN "tags_tickets" t0 ON "tags".id = t0.tag_id
WHERE (t0.ticket_id IN (1,2,[...],49,50))
Rails has run the query to find all the tickets first, then another query to gather all the
tags for all the selected tickets as the second query. This query doesn’t care if tickets
have tags or not, it will still fetch them.
Here you’ve seen a way to cause an N+1 query and how to stop it from happening.
You can remove the from app/views/projects/show.html.erb now,
because you’re done with this experiment.
This is just one way your database can be slow. Another is more insidious. It creeps
in slowly over months of the application seemingly running fine and makes it progressively
slower and slower. The problem is a lack of database indexes, and it affects many
Rails applications even today.
16.2.2 Database indexes
Database indexes aren’t a Rails feature, they’re a feature of your own database that
can greatly improve its performance when used correctly. The absence of database
indexes may not seem like a problem immediately, but when you’re dealing with
larger datasets it becomes more and more of a problem. Take for example if you had
10,000 tickets with 2,300 of them belonging to Project A. To find all the tickets for
Project A, your database sans indexes would have to do a full table scan, searching
through each ticket and determining if it belonged to Project A or not. That’s a problem,
because the more records you have, the longer this scan is going to take.