Order by reduces performance of a grouped result set
Remove LEFT if you don't need it.
The ORDER BY has ISNULL(start), yet the WHERE clause will fail if start isNULL`.  Seems like something could be simplified.
Will the table(s) become so big that they cannot be cached in RAM?  If so, we can talk about the choice of PRIMARY KEY.  (I'll need to see SHOW CREATE TABLE for this discussion.)
The query, as it stands, is destined to take some time...


It needs to look at all index rows with academy_id=3 and day=2, then filter on start.  That is currently about 5 rows; will that increase when there is more data?  Will you end up with a LIMIT?

Will the test on start be a significant factor in the filtering?  If so we can discuss a 'lazy eval' technique.

Here's one thing that may help:  Remove the LEFT JOIN members and replace the GROUP_CONCAT... with:

( SELECT GROUP_CONCAT(...) FROM members AS m
      WHERE m.id = members_attendance.member_id ) AS members,


Also, change

(DATE(members_attendance.checked_in)=CURDATE())


to

members_attendance.checked_in &gt;= CURDATE() AND
members_attendance.checked_in  &lt; CURDATE() + INTERVAL 1 DAY


and add

INDEX(event_id, checked_in)  -- in that order


(unless that table has PRIMARY KEY(event_id) -- it would help if you showed us SHOW CREATE TABLE)

Explanation

Some of the question deals with the slowdown due to ORDER BY.  Let me walk you through some of the steps:


fetch things from the first table, filtering based on the WHERE
fetch things from JOINed tables, again filtering where appropriate
GROUP BY id -- Since the joins created an explosion of rows in a tmp table, but you wanted only one row per id, this shrinks things back down.  It may require a temp table and a sort.  (Note:  My suggestion on GROUP_CONCAT avoids some of the explosion.)
ORDER BY something_else -- If the ORDER BY had been on the same value(s), it could be subsumed into the GROUP BY.  But, since it is not, there needs to be another temp table and sort.


Caveat: "temp table" may or may not be entirely in RAM.  "sort" may or may not be in RAM.  If either of these hits disk, the query will be slower.

Caveat:  If any of the SELECTed columns are TEXT or BLOB, the temp table will be headed for disk.  (The whole story is more complex; let's see SHOW CREATE TABLE.)

It may be possible to get rid of all JOINs, such as my suggestion above.  If so, then you can get rid of the GROUP BY, thereby speeding things up.

Do what you can in the directions I suggest, then let's make another pass at it.  (There may need to be further index changes.)

&lt;my-rant&gt;
    3rd party software tries to help with DB abstraction,
    but that usually gets in the way of performance.
&lt;/my-rant&gt;