Как оптимизировать сложный запрос на нагруженной базе MYSQL?

Покажите CREATE TABLE

Может у вас неиспользуемые индексы

id select_type table type possible_keys key key_len ref rows Extra

1 PRIMARY task ref stat_task,getlist,getlist_bot getlist_bot 6 const,const,const,const 8731 Using index condition; Using where

Разницы не заметили между лефт джойн и not exist. Выбор на втором варианте так как данные из второй таблицы нам не нужны. Exlplain добавил в стартовый пост

Здравствуйте. Индексы использует

id      select_type     table   type    possible_keys   key     key_len ref     rows    Extra
1       PRIMARY task    ref     stat_task,getlist,getlist_bot   getlist_bot     6       const,const,const,const 8731    Using index condition; Using where

id      select_type     table   type    possible_keys   key     key_len ref     rows    Extra
2       DEPENDENT SUBQUERY      flow    index_subquery  user_url_executor       user_url_executor       8       func,const      1       Using index; Using where

Я имел в виду, в таблице есть другие индексы, которые не используются другими запросами.

А ресурсы на их поддержание тратятся.

По EXPLAIN

Первая таблица - длина индекса - 6 байт. А индекс  Task по идее должен быть хотя бы 1+1+1+4 (если cat - 4 байта) = 7 байт.

Эти индексы не фигурируют:

Task ( status, type, provider, cat )
TaskFlow (executor_acc_id, url_id )

2 раза 

Using where

То есть InnoDB по индексу отдала данные, но mysql пришлось еще их дофильтровывать.

в таск есть еще один индекс но он используется в другом скрипте

А Вы данные со второй таблицы и не запрашивайте, а добавьте в WHERE условие что-то вроде:

AND flow.id IS NULL

Вижу в  таск 3 индекса

да и они все используются

Покажите еще

SHOW CREATE TABLE Task

И

SHOW VARIABLES WHERE 
Variable_Name IN ('innodb_flush_method', 'innodb_flush_log_at_trx_commit', 'innodb_buffer_pool_size');

а какой смысл в лефт джойн? какой выйгрыш может быть? у нас раньше он итак стоял, сменили на NOT exitst