As for the full index, you had me testing that query for a while until I realized it only uses the index if you only project that very field, i.e., your very specific query is the one that uses the index (select from table where LIKE ‘%string%’).

Of course, it still needs to process all of the tuples (if I don’t misunderstand explains output, and I hope I don’t since I don’t think there’s a way for any database to optimize those kind of queries unless we go for something like a FULLTEXT index, or move it out of the database altogether with Sphinx or Lucene), but doing it with an index is certainly more efficient.

Now, in order to take advantage of this index while projecting other columns from the result, this is all I came up with (I had to change the example because I already had data on this table):

mysql> explain select * from tasks where city in (select city from tasks where city like ‘%fi%’)\G
*************************** 1. row ***************************
id: 1
select_type: PRIMARY
table: tasks
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 150000
Extra: Using where
*************************** 2. row ***************************
id: 2
select_type: DEPENDENT SUBQUERY
table: tasks
type: index_subquery
possible_keys: city,idx_full_city
key: city
key_len: 253
ref: func
rows: 1
Extra: Using index; Using where
2 rows in set (0.00 sec)

What do you think? Is it any use? Is there a better way?

Regards