res2001

Я правильно понимаю, что это реально будет в 2 раза медленнее происходить?

Естественно.
Но по docid у вас индекс, так что должно быть достаточно быстро.

Переводите все местное время в какой-то единый стандарт. Лучше всего подходит UTC. Везде в запросах оперируйте UTC, только при выводе на экран конвертируйте обратно в свое локальное время.
UTC использовать проще всего, чем скажем MSK, т.к. конвертация из локального времени в UTC уже встроена в язык.

WHERE date >= '2020-01-01 00:00:00' and date <= '2020-01-01 23:59:59'

Ну или выделите из timestamp дату и сравните только с датой.
Дату лучше представлять в более универсальном формате: 'YYYYMMDD HH:MM:SS'
И напишите какой сервер используете.

Вы же сами уже ответили:

В случае с left join, конечно, придется дописывать лишнее в sql запрос, зато одним запросом сразу вытащим все данные.

join быстрее

как-то так:

select Name, sum(Amount) from (
  select Name, Amount from AMO
  union all
  slect Name, Zarp as Amount from PRIC
) group by Name

В вашем запросе никакие строки не объединяются. Все parent_id будут отдельными строками в результате.
Чтоб что-то начало объединяться вам нужно сгруппировать строки с помощью group by (в вашем случае группировать видимо надо по parent_id), тогда можно будет применить count(*) и он покажет количество объединенных строк по заданному критерию.

Укажите какую СУБД используете.

Для увеличения производительности вставки можно отключить/удалить индексы у таблицы, куда происходит вставка. После завершения операции снова включить. Пересоздать индекс после вставки будет быстрее, чем он будет пересчитываться после вставки каждого значения.

Кроме того обычно СУБД поддерживают операции bulk insert (пакетная вставка), возможно для этого придется конвертировать файл в формат, который понимает СУБД. У MySQL вроде такого нет, в этом случае остается только вариант, предложенный Дмитрий

• Посмотрите план выполнения.
  
• Индекс на t.external_uids и на t.id есть?
  
• Замените exist на in.
  
• 400000 - не тот объем, чтоб MS SQL на нем приседал. Может быть у вас не хватает памяти для SQL сервера и/или диски медленные?
  

Поле ID с уникальным номером и индекс по этому полю, индекс лучше кластерный. count(ID) будет выполняться достаточно быстро, но не мгновенно, конечно.

Попробуйте так: '20180814'

Вычисляете общее количество записей (N), которые можно выбрать.
Генерируете 10 случайных чисел в диапазоне от 1 до N.
Выбираете 10 записей из верхнего запроса, у которых row_id равен случайным числам.
ID выбранных записей нужно куда-то сохранить, чтоб в следующий раз их использовать.

Группируйте не по UsrCDistributionDate, а по MANAGER или лучше по MANAGER_ID, count(*) делите на количество дней в периоде.

БД с таблицей на каждый день - это не правильно.
Пришлось работать с одним программным продуктом, где каждый день генерировалась новая таблица в БД (точнее не одна, а несколько). После некоторого времени использования ПО (2-3 года, если не ошибаюсь) база перестала работать, т.к. количество таблиц стало таким большим, что движок БД отказывался работать с ней. Пришлось вручную удалять старые таблицы, чтоб реанимировать софтину.