SELECT
FIELD1, FIELD2, FIELD3, FIELD4, FIELD5
FROM
MYTABLE
WHERE
FIELD1 = .... AND
FIELD2 = .... AND
FIELD3 = ....
GROUP BY
FIELD4
;
Note that the only thing I changed are the names of the fields and the table. My query does have 5 fields in the SELECT statement and 1 table in the FROM section. The WHERE and the GROUP BY sections also looks exactly like that: 3 fields with equals condition.
The fields FIELD1, FIELD2 and FIELD3 are both PKs and indexes.
The problem: The query takes almost 8 seconds to finish (and it returns around 30 rows).
The question: Is there any way I can speed up the query, that isn't server related (increasing cache, running the database in a more powerful server, etc...)?
Search all postal codes that match TOWN == 1 (Chicago) AND Neighborhood == 001 AND ZONE == 1
and then GROUP BY the postal code. I hope this makes it clear.
Solução
problem seems with your searching method just inclosed your values like field1='value' as these are varchar and you are using with out quotes. By this your query will use index and you get performance.
Note: There is no need to use index as mysql do it its own.
Outras dicas
With the information now given
The table contains streets along with their postal codes, zone, neighbourhood and town.
You are looking up postal codes and are not interested in the streets (so you wouldn't select FIELD5 in your example as I understand it now).
You can not change the table design, but you can add indexes.
you should have an index on TOWN + NEIGHBORHOOD + ZONE + PC. This contains all information you need and points to all streets associated. The dbms should be clever enough to notice that no table access is needed as all data required is present in the index. That should speed up your query significantly.
you mention that you use indexes, make sure an index contains all fields you mention in your select
it can be that it returns only 30 rows, but it has to go through many more rows due to
GROUP BY
FIELD1
so you might want to "tighten" your query by adding "LIMIT XX", "SELECT DISTINCT FIELD 1" nad such
I suggest you to take a look to implement a partitioning strategy. For big table it's the only way to significantly improve performance.