Most beginner MySQL performance problems come from a handful of recurring issues, not exotic edge cases. Fixing these first gets you most of the benefit with the least effort.

Add indexes on columns you filter or join on. If a query has WHERE email = ? or JOIN orders ON orders.user_id = users.id, both email and user_id should typically be indexed. Without an index, MySQL scans every row in the table to find matches — fine for a hundred rows, painfully slow for a hundred thousand.

Avoid SELECT * in production code. Selecting only the columns you actually need reduces the amount of data MySQL has to read and send back, especially on tables with large text or blob columns you don't need for a given query.

Use EXPLAIN before optimizing blindly. Running EXPLAIN SELECT ... shows you exactly how MySQL plans to execute a query — whether it's using an index, how many rows it expects to scan, and where the cost is. Guessing at performance problems wastes time; EXPLAIN tells you where to actually look.

Be careful with LIKE '%term%'. A leading wildcard prevents MySQL from using a standard index at all, forcing a full table scan. If you need real text search, consider a FULLTEXT index or, for larger applications, a dedicated search tool.

Paginate with LIMIT and OFFSET, but watch large offsets. LIMIT 20 OFFSET 10000 still has to scan through the first 10,000 rows internally before returning your 20. For deep pagination on large tables, keyset pagination (filtering by the last seen ID instead of an offset) scales far better.

Don't over-normalize or over-index either. Every index speeds up reads but slows down writes and takes disk space. Index the columns you actually query on — usually foreign keys and anything in a WHERE, JOIN, or ORDER BY clause — not every column defensively.

Start with indexes and EXPLAIN; those two habits alone resolve the majority of "why is this query slow" questions beginners run into.