Running EXPLAIN in a SQL client improve performances on production server
Use JOIN .. ON to establish how the tables are related.  (Actually a "self-join" in this case.)
Since you are building the WHERE clause, get rid of the spurious stuff about 1 at the end.
If version cannot be negative, use &gt; 0 instead of &lt;&gt; 0; this might be easier to optimize.
Since you are JOINing on executionNumber and lineNumber, there is no need to repeat the filtering on them.


Something like this:

SELECT  t.*
    FROM  myTable AS t,
    JOIN  myTable AS t2
      ON   t2.lineNumber = t.lineNumber
      AND  t2.executionNumber = t.executionNumber
    WHERE  t2.version = 0
      AND  t.version &gt; 0
      AND  t2.executionNumber='87710'
      AND  t2.lineNumber IN (24000,24001,24002,24003,[...],25996, 25997,25998,25999 )
    ORDER BY  t.lineNumber, t.version &gt; 0, t.recordDate DESC;


Now it is easier to see what INDEXes are needed.  (Please provide SHOW CREATE TABLE; meanwhile, I will guess.)

I think myTable needs both of these "composite" indexes:

INDEX(version, executionNumber, lineNumber)
INDEX(executionNumber, lineNumber, version)


Then show us EXPLAIN SELECT ....  I think t2 will be referenced first, using the first index.  Then t will be reached into using the second.  In both cases, the "Rows" should be much less than what you saw.

There will be a "filesort" and probably "using temporary".  They are unavoidable due to the complexity of the ORDER BY.

I assume the table is ENGINE=InnoDB?  Then I don't see how 5.7.xx would end up with any inconsistencies in EXPLAIN.  Gone are the days of re-probing to get statistics at the 'wrong' time.

I'm pretty sure the Optimizer has no 'cache' for explain-plans.  However, the plan may change from one day to the next, due to lots of inserts, etc.