Optimizing a MySql query
Based on the EXPLAIN, I would recommend focusing on second SELECT in the UNION.  It is probably the slowest piece, and the hardest to optimize.  Can you explain what it is doing?

One thing to try is to use literals in place of @_START and @_END.  @variables, even if constant, do not optimize well.

You have a lot of non-sargable expressions in the WHERE clauses.  See http://en.wikipedia.org/wiki/Sargable
Rewrite them.  One of note is that

@prevDate = DATE_FORMAT(c.`end`,'%Y-%m-%d')


is the same as

@prevDate = c.`end`


because of the way DATETIME works.  Fix all the non-sargable expressions; that will give the optimizer more options.

You would be better turning this into INT:

`duration` varchar(5) DEFAULT NULL,


As a VARCHAR it is useless in an index.  If you need non-integer values, either use NULL or have an extra column.

Please explain what the query is supposed to do -- in English.

Is limit  5000000 real?  Or an optimization trick?

What version of MySQL are you using?

(called, callid, and calling look so much alike that the query is hard to read.)

If you must name the INDEXes, at least be consistent:

KEY `called end` (`calling`,`end`),


Actually (called, end) might be better, at least for Derived #3.  I can't tell, but this might be the quickest partial fix.  It might avoid a 'filesort' necessary for

ORDER BY  c.called, c.`end`


However, due to the mixing of ASC and DESC, this won't be helped:

ORDER BY  c.called, c.`end` desc


Will it run any faster without @S := and @G :=?  These seem to do nothing inside the query, but perhaps lead to some kind of 'output' from the whole query.  And perhaps their presence forces the optimizer to do something sub-optimal.

Carrying data from one row to the next (re: @nextComp) is likely to be an optimization-killer.  One trick to avoid such things, is to have a sequence number (perhaps an AUTO_INCREMENT in a temp table) that lets you do a "self JOIN" to match up a row and the preceding row.  This is complex, but potentially beneficial.

You have a lot of redundant indexes; DROP them.  (This won't help the question in hand.)

After you have fixed what you can, post the new SELECT and the new CREATE TABLE.  Then we can continue this discussion.