Bizarrely high rows read when there's only 1 row in the table?

[davidguy3237]

I've been trying to learn NextAuth, and opted to try out Prisma and Planetscale for the database side of things, but as I was looking into Planetscale's Insights section, I noticed that the rows read for some of the queries was weirdly high. I literally only have 1 row that exists across all of my tables, but Insights is consistently reporting rows read of over 100. This might entirely be an error on my part somewhere, I'm just not sure how there can be more rows read than exists in the table. I'm just concerned about the implications as the project scales. I apologize for any mistakes, but I'd really appreciate any advice on the matter.

I took this screenshot right after testing my Credentials Provider NextAuth login function

As you can see from Prisma Studio, there is only 1 row that exists, which is inside User.

Here is the relevant part of my Prisma schema if that is at all helpful

model User {
  id            String    @id @default(cuid())
  name          String   @unique
  email         String   @unique
  emailVerified DateTime?
  image         String?
  password      String?
  role          UserRole @default(USER)
  accounts      Account[]
  isTwoFactorEnabled Boolean @default(false)
  twoFactorConfirmation TwoFactorConfirmation?

  @@index([name, email])
}

model Account {
  id                 String  @id @default(cuid())
  userId             String
  type               String
  provider           String
  providerAccountId  String
  refresh_token      String?  @db.Text
  access_token       String?  @db.Text
  expires_at         Int?
  token_type         String?
  scope              String?
  id_token           String?  @db.Text
  session_state      String?

  user User @relation(fields: [userId], references: [id], onDelete: Cascade)

  @@index([userId])
  @@unique([provider, providerAccountId])
}

The only Prisma queries that get used during the login auth flow are:
db.user.findUnique({ where: { email } });
db.user.findUnique({ where: { id } });
db.account.findFirst({ where: { id } });

==============================================
EDIT:
So I managed to find in the Planetscale docs, an explanation for each column. Frankly, I should have looked at the docs first before asking here, but at least this might let others that might also be a bit confused know.

Rows returned — The total number of rows fetched by a SELECT statement. This includes all times the query has run in the displayed time frame.
Rows read — The total number of rows read. This includes all times the query has run in the displayed time frame. This is the number that directly affects your rows read billing calculation.
Rows read/rows returned — The result of dividing total rows read by rows returned in a query. A high number can indicate that your database is reading unnecessary rows, and they query may be improved by adding an index.
Rows affected — The total number of rows modified by an INSERT, UPDATE, or DELETE statement. This includes all times the query has run in the displayed time frame.

In summary, the number I was reading under Rows read, was the total number of rows that specific query has read in the past 24 hours, which makes significantly more sense. For some reason I thought it was reporting that a single query read more rows than exists on the table, which was NOT what was happening.

If someone can reconfirm my thought process, this discussion can be marked closed.

[mscoutermarsh]

Yes, correct. The column to look at for inefficient queries is: Rows read/rows returned.