ex. $sql = “SELECT id FROM users where email = ‘uniq@email.com’ LIMIT 1″;

If you’re executing count(*) queries for such result sets MySQL will perform the join even if you use LEFT JOIN so it is not needed which slows down things considerably. In similar way MySQL generates full rows while executing queries with limit befor…

While this works when performing LEFT JOINS, with INNER JOINS it’s a different thing.
Let’s say we want 10 records, starting from offset 500000, where i & 10000, like in the above example, but let’s perform an innerj join instead…
The first subquery will return the requested 10 results, and asuming in the res table there are rows that don’t match some rows returned by the subquery, then the result will be less than 10 rows…

Yes I often use this too, in MySQL and in Postgres, it is just one of the tricks of the trade ! I believe the optimizer should be able to move ORDER BY and LIMIT around inside the execution plan by itself but since it isn’t, doing it yourself is the way.

Recently I had a huge search query (in Postgres) which was horrendously slow. It has various conditions like GPS coordinates, date, item type, etc, and the all-time favourite, union from a huge archive table and an active table, plus a 5-way JOIN with a few aggregates.

The archive + active is quite common so I’ll drop my way of doing it :

- first query the active table and store the results in a temporary table.
- since i use ORDER BY + LIMIT, I can then compute the max() or min() (depending on the order) or the relevant row
- then I query the archive table, but I know that rows which have the ORDER BY field greater (or lower depending on the order) to the value computed above will not appear in the final result set since the first query from the active table already gave me enough rows to satisfy my LIMIT. I then add a WHERE condition to filter out the rows BEFORE sorting them. Postgres will bitmap-index-scan on a boolean OR/AND mix of my indexes so it will never even look at those rows that don’t match.
- I insert the results of this query in the temp table
- I sort and limit the temp table and fetch it
- I perform all my joins from the temp table (no freaky IN() from php)

It went from a few minutes to a few tens of milliseconds. Not bad I may say. Use this trick if you need ! It works very very well with MySQL too.