How Lina's AI-Written SQL Doubled Last Month's Sales - The Habit of Checking Row Counts

2026-10-24 Reading time: About 10 min Difficulty: Introduction

You asked an AI to write SQL. It ran with no errors, but the numbers do not add up. Has that happened to you? In this article, Linny-senpai and Lina build one habit: check the row count and one row of the result with your own eyes.

What you will learn

• Why SQL that runs without errors can still answer a different question
• How to spot a JOIN that added rows, and two ways to fix it
• The habit of counting with the same condition before an UPDATE, and a 3-step check for AI answers

Introduction

Conclusion: No errors does not mean a right answer. If sales look doubled, count rows first.

1. What Happened? Lina Ran the AI's SQL As-Is

Conclusion: The SQL joining 3 tables returned 18 rows, not 1 per member, so the total grew.

Lina's practice data for her gym, gym.db, has three tables.

sqlite3 gym.db <<'EOF'
DROP TABLE IF EXISTS members;
DROP TABLE IF EXISTS enrollments;
DROP TABLE IF EXISTS payments;
CREATE TABLE members (id INTEGER PRIMARY KEY, name TEXT, city TEXT);
INSERT INTO members VALUES
  (1,'Pip','Tokyo'), (2,'Momo','Tokyo'), (3,'Kai','Sapporo'),
  (4,'Luna','Tokyo'), (5,'Nico','Tokyo'), (6,'Rio','Osaka'),
  (7,'Sora','Osaka'), (8,'Tama','Osaka'), (9,'Ana','Lisboa'),
  (10,'Ken','Porto'), (11,'Yuki','Lisboa'), (12,'Leo','Austin');
CREATE TABLE enrollments (member_id INTEGER, plan TEXT, ended_at TEXT);
INSERT INTO enrollments VALUES
  (1,'student','2025-03-31'), (1,'basic','2026-03-31'), (1,'pro',NULL),
  (2,'basic',NULL),
  (3,'basic','2025-08-31'), (3,'student','2026-01-31'), (3,'pro',NULL),
  (4,'student',NULL),
  (5,'pro','2025-06-30'), (5,'basic','2026-02-28'), (5,'pro',NULL),
  (6,'basic',NULL),
  (7,'basic','2025-09-30'), (7,'pro','2026-04-30'), (7,'pro',NULL),
  (9,'basic',NULL), (10,'student',NULL), (11,'basic',NULL);
CREATE TABLE payments (member_id INTEGER, amount INTEGER);
INSERT INTO payments VALUES
  (1,4500), (2,3000), (3,4500), (4,2000), (5,4500),
  (6,3000), (7,4500), (9,3000), (10,2000), (11,3000);
EOF

$ sqlite3 gym.db "SELECT m.name, e.plan, p.amount
FROM members m
JOIN enrollments e ON e.member_id = m.id
JOIN payments p ON p.member_id = m.id;"

Pip|student|4500
Pip|basic|4500
Pip|pro|4500
Momo|basic|3000
Kai|basic|4500
Kai|student|4500
Kai|pro|4500
Luna|student|2000
Nico|pro|4500
Nico|basic|4500
Nico|pro|4500
Rio|basic|3000
Sora|basic|4500
Sora|pro|4500
Sora|pro|4500
Ana|basic|3000
Ken|student|2000
Yuki|basic|3000

$ sqlite3 gym.db "SELECT SUM(p.amount)
FROM members m
JOIN enrollments e ON e.member_id = m.id
JOIN payments p ON p.member_id = m.id;"

70000

$ sqlite3 gym.db "SELECT SUM(amount) FROM payments;"

34000

2. Count First: 12 Members, 18 Rows

Conclusion: One line per member means no more rows than members. 18 rows for 12 is too many.

$ sqlite3 gym.db "SELECT COUNT(*) FROM members;"

12

$ sqlite3 gym.db "SELECT COUNT(*)
FROM members m
JOIN enrollments e ON e.member_id = m.id
JOIN payments p ON p.member_id = m.id;"

18

$ sqlite3 gym.db "SELECT * FROM enrollments WHERE member_id = 1;"

1|student|2025-03-31
1|basic|2026-03-31
1|pro|

A relationship where "one person has several records" is called one-to-many. When you JOIN a one-to-many table, the result gets as many rows as the "many" side has.

3. Two Fixes: Keep Only Current Rows / Total First

Conclusion: Keep only current plan rows, or total per member before joining. Both give 10.

Fix 1: Keep only the current plan rows

$ sqlite3 gym.db "SELECT COUNT(*) FROM enrollments WHERE ended_at = NULL;"

0

$ sqlite3 gym.db "SELECT COUNT(*) FROM enrollments WHERE ended_at IS NULL;"

10

$ sqlite3 gym.db "SELECT m.name, e.plan, p.amount
FROM members m
JOIN enrollments e ON e.member_id = m.id
JOIN payments p ON p.member_id = m.id
WHERE e.ended_at IS NULL;"

Pip|pro|4500
Momo|basic|3000
Kai|pro|4500
Luna|student|2000
Nico|pro|4500
Rio|basic|3000
Sora|pro|4500
Ana|basic|3000
Ken|student|2000
Yuki|basic|3000

Fix 2: Total first, then join

$ sqlite3 gym.db "SELECT m.name, t.total
FROM members m
JOIN (SELECT member_id, SUM(amount) AS total
      FROM payments GROUP BY member_id) t
  ON t.member_id = m.id;"

Pip|4500
Momo|3000
Kai|4500
Luna|2000
Nico|4500
Rio|3000
Sora|4500
Ana|3000
Ken|2000
Yuki|3000

4. Count Before You Change: An UPDATE Without WHERE

Conclusion: Before UPDATE, run COUNT(*) with the same WHERE and confirm the expected 1 row.

UPDATE members
SET city = 'Osaka'
WHERE id = 3;

$ cp gym.db gym-backup.db

$ sqlite3 gym.db "UPDATE members SET city = 'Osaka'; SELECT changes();"

12

$ sqlite3 gym.db "SELECT city, COUNT(*) FROM members GROUP BY city;"

Osaka|12

$ cp -i gym-backup.db gym.db

cp: overwrite 'gym.db'? y

$ sqlite3 gym.db "SELECT COUNT(*) FROM members WHERE id = 3;"

1

$ sqlite3 gym.db "SELECT * FROM members WHERE id = 3;"

3|Kai|Sapporo

$ sqlite3 gym.db "UPDATE members SET city = 'Osaka' WHERE id = 3; SELECT changes();"

1

5. A 3-Step Check When You Ask AI

Conclusion: Predict rows, run COUNT(*), and check one row to catch too many or too few.

$ sqlite3 gym.db "SELECT COUNT(*) FROM members WHERE city = 'Tokyo';"

4

$ sqlite3 gym.db "SELECT name FROM members WHERE city = 'Tokyo';"

Pip
Momo
Luna
Nico

$ sqlite3 gym.db "SELECT 'tokyo' = 'Tokyo', 'Tokyo' = 'Tokyo';"

0|1

Here are the common stumbling points in one table.

Mini Exercises

Conclusion: Try the 3 steps on gym.db: count, look at one row, and decide for yourself.

Exercise 1: How many members are on the pro plan now?

Task: You asked an AI for "the number of members currently on the pro plan," and it returned SELECT COUNT(*) FROM enrollments WHERE plan = 'pro';. The result is 6. Check whether it is right.

$ sqlite3 gym.db "SELECT member_id, plan, ended_at FROM enrollments WHERE plan = 'pro';"

1|pro|
3|pro|
5|pro|2025-06-30
5|pro|
7|pro|2026-04-30
7|pro|

$ sqlite3 gym.db "SELECT COUNT(*) FROM enrollments WHERE plan = 'pro' AND ended_at IS NULL;"

4

Exercise 2: Count before you change

Task: Luna moved to Osaka. Before changing her city to Osaka, confirm that only one row will change, and then run it.

$ cp gym.db gym-backup.db

$ sqlite3 gym.db "SELECT COUNT(*) FROM members WHERE name = 'Luna';"

1

$ sqlite3 gym.db "SELECT * FROM members WHERE name = 'Luna';"

4|Luna|Tokyo

$ sqlite3 gym.db "UPDATE members SET city = 'Osaka' WHERE name = 'Luna'; SELECT changes();"

1

Review

Conclusion: Check the row count and one row of AI SQL, then use it with confidence.

3-Line Summary

Conclusion: Extra JOIN rows, a missing WHERE, odd spellings: counting rows catches them all.

1. Doubt it when there are more rows than members - joining a one-to-many table adds rows and inflates totals
2. Count before you change - before UPDATE, run COUNT(*) with the same WHERE
3. Predict, count, look at one row - check AI-written SQL with these 3 steps