select count(*) from (select ID from ((SELECT ID FROM TBL_RES_USR) ORDER BY SCORE DESC) a where a.ID=(SELECT DISTINCT(USER_ID) FROM TBL_RES_SCORE_DATA WHERE COMPLETENESS>=80 and USER_ID=a.ID ) AND NOT((select COUNT(*) from TBL_USR_ORGANIZATION_INFO b where TO_DATE =(SELECT max(TO_DATE) from TBL_USR_ORGANIZATION_INFO where USER_ID=a.ID AND DEL_IND =’n') AND USER_ID=a.ID AND DEL_IND =’n’ and ORGAN_NAME In(’SAP’))) and a.ID=(select distinct(USER_ID) from TBL_RES_USER_SKILLS where USER_ID=a.ID and SKILL_NAME=’JAVA’ )and a.ID=(select distinct(USER_ID) from TBL_RES_SUMMARY where USER_ID = a.ID and TOTAL_EXPERIENCE<=100)and (a.ID=(select distinct(USER_ID) from TBL_RES_SUMMARY where (timediff(date_add((select curdate()),INTERVAL -’22:12′ HOUR_MINUTE),date_add(LAST_LOGIN,INTERVAL -’22:12′ HOUR_MINUTE))/24)<=365 and USER_ID=a.ID)))as Counts;

+———-+
| count(*) |
+———-+
| 4333 |
+———-+
1 row in set, 8666 warnings (1 min 22.93 sec)

select (IFNULL(ACOS(0.796641758191*COS(RADIANS(l.latitude))*(-0.525545896347*COS(RADIANS(l.longitude)) + -0.850765250132*SIN(RADIANS(l.longitude))) + 0.604451742578*SIN(RADIANS(l.latitude))), 0.00000)*6370298.85223) as dis, l.* from yellow_pages l WHERE match(sic_des) against(’”hotel*” ‘ in boolean mode) and ( longitude BETWEEN -122.159246013 AND -121.250753987 and latitude BETWEEN 36.827530043 AND 37.551269957 or zip in(95050,95051,95052,95053,95054,95055,95056)) order by dis LIMIT 0, 10

i use php(v5.2) to connect to mysql(v5.02) but it run sooooo long
any idea??

thanks

SELECT * FROM a WHERE b=1 AND c=2 ORDER BY d

Here, an index on (b,c,d) will avoid MySQL using filesorting.
If three indexes are put on b, c and d, will MySQL be able to use index merge on d to avoid filesorting ?

Ah… This is typo it should be 30ms not 0.3ms So pretty much it works as good as BETWEEN 1 and 2 query would
BETWEEN is never optimized to IN even though it is often possible – you can do it manually though

Q3 25 0.3

was this on a “switched” index that doesn’t show on the description ?

Regarding BETWEEN: shouldn’t the optimized transform this ?

The query you’re running is exactly query which can’t use multi column index completely – BETWEEN makes it to scan only first key part this is why with it the performance is bad. If you have query as you described the index should be (j,i) not (i,j)

Now you also see two more things with your explain – first Index Merge is not really used here – it is just range scan by one or other index. Second there is a huge difference between IN and BETWEEN – IN allows scanning both keyparts while BETWEEN does not.

mysql> explain SELECT SQL_NO_CACHE sum(length(val)) FROM t1000c WHERE j=2 AND i BETWEEN 1 AND 2;
+—-+————-+——–+——-+—————+——+———+——+——-+————-+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+——–+——-+—————+——+———+——+——-+————-+
| 1 | SIMPLE | t1000c | range | i | i | 8 | NULL | 14729 | Using where |
+—-+————-+——–+——-+—————+——+———+——+——-+————-+
1 row in set (0.00 sec)

mysql> explain SELECT SQL_NO_CACHE sum(length(val)) FROM t1000c WHERE j=2 AND i IN (1,2);
+—-+————-+——–+——-+—————+——+———+——+——+————-+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+——–+——-+—————+——+———+——+——+————-+
| 1 | SIMPLE | t1000c | range | i | i | 8 | NULL | 33 | Using where |
+—-+————-+——–+——-+—————+——+———+——+——+————-+
1 row in set (0.00 sec)

Peter, what version of mysql are you using ?

x time
————–
2 48.57
3 97.82
4 147.25
5 197.1
10 443.31
15 691.06

If goes downhill from there. So, very limited range of aplicability.
On the other hand, I’ve got consistent results from 2 index table, surprisingly, much faster than your results. This is why I wanted to see your data. I’m not sure why my results are so much faster:

x time
————–
2 46.08
10 46.14
20 46.24

Anyway, the 2 column index is only useful for a limited range of values. It can only be used as performance boost in same specific cases in addition to single column indexes.
I’ve used a 8 GB RAM computer dual core CPU. Tables are less than 1 GB in size. The index cache was set at 4 GB. Mysql version 5.0.67 ( i was doing testing for bug 29857).

mysql> show index from t1000;
+——-+————+———-+————–+————-+———–+————-+———-+——–+——+————+———+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+——-+————+———-+————–+————-+———–+————-+———-+——–+——+————+———+
| t1000 | 1 | i | 1 | i | A | 1001 | NULL | NULL | | BTREE | |
| t1000 | 1 | j | 1 | j | A | 1001 | NULL | NULL | | BTREE | |
+——-+————+———-+————–+————-+———–+————-+———-+——–+——+————+———+
2 rows in set (0.00 sec)

mysql> select count(*) from t1000;
+———-+
| count(*) |
+———-+
| 18000000 |
+———-+
1 row in set (0.00 sec)

(the other table, t1000c, has same data only combined index instead of simple index).

I did not do the timing for histogram. You have the table information and so can do the run yourself and share results