Мониторинг выходного файла при выполнении длинного запроса MySQL в этот выходной файл - PullRequest
Новая
       23

Мониторинг выходного файла при выполнении длинного запроса MySQL в этот выходной файл

0 голосов
/ 12 января 2020

Итак, у меня очень длительный MySQL запрос: Оптимизация сравнения данных в двух больших MySQL таблицах

Видимо, есть результаты: после прерывания запроса я обнаружил, что Выходной файл действительно был изменен и имеет несколько тысяч записей. Однако результаты были сброшены в файл в тот момент, когда я прервал длительный запрос .

Я использовал команду:

mysql> SELECT ar.email FROM activation_request ar WHERE ar.date_confirmed is not null AND NOT EXISTS (SELECT 1 FROM user u WHERE u.username = ar.email) INTO OUTFILE '/tmp/results_after_adding_indexes.csv';

Как я могу контролировать / проверять это в это время? Файл был создан в файловой системе, но он пуст (до конца или прерывания запроса; что будет первым).

Ответы [ 3 ]

0 голосов
/ 12 января 2020

Некоторые запросы выполняются линейно. То есть они производят другую строку в обычном темпе.

Некоторые запросы выполняют 99% работы, прежде чем испустить даже «первую» строку. Это легко увидеть, если запрос имеет ORDER BY.

Некоторые соединения вычисляют весь результат перед отправкой что-либо обратно клиенту , Некоторые соединения блокируют выход.

Проблема с подключением может быть решена. Но просто не практично «отслеживать» запрос с чем-то вроде сортировки.

0 голосов
/ 14 января 2020

Это ваш запрос, верно? И PK id, правильно? 

SELECT  l.email 
    FROM activation_request l 
    LEFT JOIN user r ON r.username = l.email 
    WHERE l.date_confirmed is not null 
      AND r.username IS NULL

Используя некоторый код приложения, создайте al oop на id, возможно, 10000 за раз: 

SELECT  l.email 
    FROM activation_request l 
    LEFT JOIN user r ON r.username = l.email 
    WHERE l.date_confirmed is not null 
      AND r.username IS NULL
      AND l.id BETWEEN 1 AND 10000;   -- added

Время который; затем измените последнюю строку на 

      AND l.id BETWEEN 10001 AND 20000;

Et c.

Это будет:

  • Предоставить требуемый список строк с пропущенными пользователями, хотя и по частям .
  • После первого фрагмента вы можете экстраполировать, чтобы получить ожидаемое общее время.
  • После нескольких фрагментов вы можете почувствовать, изменяется ли он по скорости.
  • Вы можете сложить данные вместе, чтобы получить индикатор выполнения.

Выше предполагается, что ids "плотные"; это не идентификаторы удалены. Если есть удаленные идентификаторы, то чанки не будут состоять из 10000 строк (а, скорее, будет меньше строк). Эту проблему можно решить с помощью SELECT id FROM .. WHERE id > $leftoff ORDER BY id .. LIMIT 10000,1, чтобы определить следующую конечную точку.

Подробнее о чанкинге: http://mysql.rjweb.org/doc.php/deletebig#deleting_in_chunks (Внимание: это говорит об удалении.)

Если вы сделаете несколько фрагментов по методу NOT EXISTS, вы сможете почувствовать, что быстрее. Предостережение: запустите дважды, чтобы избежать кеширования, которое могло испортить время.

0 голосов
/ 12 января 2020

Поскольку INTO OUTFILE не поддерживает опции для разбивки на страницы вывода, я считаю, что вам нужно написать собственный скрипт экспорта.

(Обратите внимание, вы также можете увидеть LOAD DATA опции для полноты, как указано в документации INTO OUTFILE, но единственное, что можно надеяться, это опция LINES, которая предназначена для пользовательских разделители строк.)

При условии, что вам не нужны опции механизма БД в строках записи, скрипт прост:

  1. Версия вашего отчета / экспорта "gimme all" - если ваш набор данных не слишком велик для этого, в этом случае включите цикл подкачки;
  2. зацикливание на результатах для выполнения простого преобразования;
  3. хранить исходящие строки в массиве на пути к файлу;
  4. записывать эту очередь в файл каждые n строк;
  5. и следить за тем, чтобы не сбрасывать последние биты набора записей только потому, что они не содержат n строк в последнем блоке.
...