Select for indexed field with >= is much faster than with =
With &gt;=, the optimizer had two indexes to choose from.  Apparently it chose (exp_time).  Please provide EXPLAIN SELECT ... to confirm this. Also run EXPLAIN FORMAT=JSON SELECT ...

With =, the optimizer still has two to choose from, but probably picked = (asset_id). But there were a lot of 71's, so it turned out to be a bad choice.

That choice can be improved by having INDEX(asset_id, exp_time) in place of simply (asset_id).  This may run faster than even 0.5s.  This 'composite' index can use both parts of the WHERE clause, thereby being more efficient.  (The &gt;= version can't use both columns of a composite index because it can't handle 2 ranges at the same time.)

And even better than  (asset_id, exp_time): (is_demo, asset_id, exp_time) or (asset_id, is_demo, exp_time).

It could be that the "statistics" are stale -- run ANALYZE TABLE Deals to see if things improve.  But don't hold your breath; this is not a panacea.