What feature of MySQL is causing such a difference in query processing?

Question

MySQL

Greetings. Let's assume that I want to get message data from the messages table , which is a day (or more) older than the current one (for the current one, I have its id).
Trial request:

SELECT * FROM messages WHERE id = 
  (SELECT MAX(id) FROM messages WHERE 
     id < 40000 AND dt <= DATE_SUB('2016-04-18 23:23:23', INTERVAL 24 HOUR));

Functions quickly. There is an index on the dt field , although I'm not sure if it is used in DATE_SUB ()

SET @myid = 40000;
  (SELECT MAX(id) FROM messages WHERE 
     id < @myid AND dt <= DATE_SUB('2016-04-18 23:23:23', INTERVAL 24 HOUR));

Why?! What is the nature of the request?
In production code, I use a stored procedure that passes myid . And, again, it works quickly.

DROP PROCEDURE IF EXISTS `TEST`;
DELIMITER $$
CREATE DEFINER=`root`@`localhost` PROCEDURE `TEST`(IN myid INT)
BEGIN
  (SELECT MAX(id) FROM messages WHERE 
     id < myid AND dt <= DATE_SUB('2016-04-18 23:23:23', INTERVAL 24 HOUR));
END$$
DELIMITER ;
CALL TEST(40000);

Answer 1

Look in explain to see what the scheduler thinks about these requests. There is a strong suspicion that the storage and the constant request go by index by id, the request with a variable is somehow different.
One obvious pitfall:
The value of a variable can change during query execution.
A constant value in the request and the storage argument cannot.
Accordingly, my assumption is that the stupid optimizer does not look at the fact that the variable does not change in any way in the request, which means that it cannot simply take the index by id and something else must be done. Most likely seq scan - judging by the name of the table, there is much more data that falls under the dt <= date condition than data that does not fall under it. For good work on the index, the inverse property is needed.