Home > front end >  COUNT with JOIN and WHERE clause - very slow query
COUNT with JOIN and WHERE clause - very slow query

Time:07-04

The queries on the website I am working on are pretty slow (there are only about 300k records in the database and some queries take more than 30 seconds), so I wanted to find the problem and decided to do some performance tests with some simple queries, here you will find 3 different scenarios:

 SELECT count(*) FROM offer_test
 INNER JOIN searchmod_location_city
    ON (offer_test.city_id = searchmod_location_city.id)

 SELECT count(*) FROM offer_test
 WHERE price > 500000

 SELECT count(*) FROM offer_test
 INNER JOIN searchmod_location_city
    ON (offer_test.city_id = searchmod_location_city.id)
 WHERE price > 500000

The first select takes about 0.2s, second one about 0.06s, and the third one which is simply combination of two previous selects takes about 20 seconds, this seems very strange to me, I would expect it to take no longer than sum of first and second query. Of course I don't really need the JOIN to count offers in the last scenario (price column is in offer_test table), but it is just for test purposes and understading this behaviour will help me with optimization of similar queries in the system (more JOINS and more conditions in the WHERE clause).

(There are of course indexes on price column, and on foreign_keys columns).

Can someone explain to me why the last query takes so long and what to do about it?

Below you will find explain for the last query enter image description here

CodePudding user response:

The reason for the timings may be seen in the EXPLAINs for the other two.

The 3rd query is not really the combination of the other two -- it is also counting how many rows are in both tables based on the city. What counts did you get for the 3 queries? Often a JOIN "inflates" a COUNT(*) since the COUNT is done against the JOIN of the two tables.

If you need the count to apply only took one table, the formulation needs to be different.

It would help to have

INDEX(price, city_id)

This is likely to be better than simply INDEX(price). When you add the 2-column "composite" index, DROP the 1-column index.

I assume the other table has PRIMARY KEY(id)?

How many rows in each table?

  • Related