Optimizing a slow query to better use indexing
Your query seems to be simply this:

SELECT time_stop, some_count
    FROM foo
    WHERE user_id = 1
    AND time_start &gt;= '2016-07-27 00:00:00'
    AND time_stop &lt;= '2016-07-27 23:59:59'
 ORDER BY some_count DESC LIMIT 1;


You need an index on (user_id,time_start) -- in that order -- and, assuming start is always earlier than stop, adding the seemingly-unnecessary AND time_start &lt;= '2016-07-27 23:59:59' will allow the database to avoid even considering rows with time_start values later.  

Also adding time_stop to the same index will not help you, for the same reason that the telephone directory won't help you find all people with first names beginning with the letter L.  Adding some_count to the index also won't help, for the same reason.  In a multi-column index, the values in column B are sorted within identical groups of column A (hence the telephone directory reference). The values in column C are sorted within identical groups of B, etc... so if A is an equality comparison, and B is a range, as in your query, those are easy to pinpoint... but the values of C appear random.  For C to be usable in an index, B needs also to be an equality comparison, which it is not, in your case.

However, if these are the only columns you're reading, then adding those columns to the index (to the right of user_id and time_start) could be useful for a different reason -- when a query uses an index that contains all the columns selected, it's a "covering index," and the entire result can be read directly from the index, instead of the main table, potentially giving a benefit that you have to weigh against the cost of maintaining larger indexes.