Select query is too slow
It has to do with the way VARCHAT/TEXT/BLOB field are handled.
I personally observed this in an RDS instance
I had taken a table with 25 million rows which had a TEXT field in it and ran this
SELECT DISTINCT LENGTH(colname) FROM tblname;

and I saw just 2 numbers, 3 and 10.
I converted the field from TEXT to VARCHAR(10). What this did was increase the amount of RAM occupied in the InnoDB Buffer Pool. I verified this from a CloudWatch graph, see Free RAM dip right after doing this and the graph stayed that way. The number of free buffer pool pages dropped accordingly.
I am not the only to have seen this phenomenon. Someone once posted a blog entitled &quot;Drain your InnoDB Buffer Pool by moving large fields out of MySQL&quot; who had observed similar Buffer Pool weirdness.
What is interesting is that Bill Karwin had commented on this in a DBA StackExchange post (MySQL stores BLOB in innodb buffer pool (innodb_buffer_pool_size)?). He mentioned that BLOBs will occupy InnoDB Buffer Pool Pages. Shrinking them can make data fit in the InnoDB Buffer Pool better could work for you or against you depending on the size of the data.
In your particular case, you only have 269 rows. This should let you know that handling TEXT fields requires some extra I/O in RAM or on disk. You are using MEDIUMTEXT, which can hold up to 16M. Given innodb_page_size = 16384 (16k), a MEDUIMTEXT value can occupy up to 1024 pages. This potential means you are dragging a lot of space from disk based on how much data is in each MEDIUMTEXT field. You may have to live with it.
SUGGESTIONS

If you keep MEDUIMTEXT, You may have to increase innodb_buffer_pool_size to accommodate
If you would like to change from MEDUIMTEXT, please run SELECT LocalDescription,LocalFacilitiesDescription FROM test.hotels where Id &gt; 0 PROCEDURE ANALYSE();. This will suggest the proper datatype for those columns. (BTW I have discussed the use of PROCEDURE ANALYSE()).