My small web project had a page that took eight seconds to load, and I blamed the frontend
for a week. I tried lazy loading images, trimming the CSS, and even moving to a smaller font file.
Nothing changed, and the page still showed a blank white screen until the data finally arrived. It was a
simple orders list for a friend's shop, with about 40,000 rows in the table. Finally I opened the database and
ran the exact query from my code by hand. It took 7.6 seconds on its own, so the browser had
never been the problem. The query filtered orders by customer id and sorted by date, which sounded harmless to me.
I had never created an index on that customer column, because the project started with ten rows. Someone suggested running
EXPLAIN before the query to see what the database was doing. The output said it was reading every single row to
find one customer's orders. I added one index on customer id and date, and the same query dropped to 12 milliseconds.
I ran it three times because I did not believe the first result. The funny part is how
little code the fix needed, only one line in the database. I also found a second query on the
dashboard doing the same thing, and fixed it the same way. Now the whole page opens in under a
second, even on my slow phone connection. I wasted days polishing things that were never slow, which is
slightly embarrassing to admit. Since then I look at the database first whenever something feels slow in a web
app. I am still unsure how many indexes are too many, because I read that they slow down writes.
For a shop with a few hundred orders a day, I assume it does not matter
yet. What was the first slow query that taught you to check the database before the frontend?