Конечно, можно.
Например, полным перестроением дерева (фактически - копированием) в сортированном порядке в балансированную структуру (которая элементарно строится, даже заранее, на основании только количества узлов). Это будет не очень эффективно, но ничего в том невозможного нет.
В принципе хороший вариант. Выводить MsgBox с адресом активной ячейки в обоих системах.. возможно даже с доп. кнопками копирования адреса в буфер обмена. Ну и/или хоткей прикрутить можно.
Сделай страницу, которая копирует id с "главного" документа и заполняет колонку наименований с присланного документа с использованием ВПР(). Если же это показано содержимое одной колонки - подели её на две. Или используй ВПР() по выражению.
В Slow Log есть и дата-время, и учётная запись, от имени которой выполнен запрос, а не только текст медленного запроса.
Кроме того, коли время повторяемо, можно включить на время General Log - и там чётко увидеть весь сеанс, из которого прилетел запрос. Как правило, этого достаточно для идентификации. А ведь параллельно можно вести мониторинги и смотреть логи других приложений и самой ОС...
В общем, проблемы-то нет. Просто надо озаботиться.
PS. Не пишите факты в комментариях - добавляйте их в текст вопроса.
Там не может быть несовпдаения наборов, если создается строка с action_type = 22 и type = 'give', то сразу за ним создается type = 'remove' и action_type = 3
В структуре таблицы есть constraint, который ГАРАНТИРУЕТ совпадение наборов? что, нету? Всё, привет - несовпадение наборов МОЖЕТ БЫТЬ, пусть и как результат сбоя, ошибки, ручного ввода, в том числе и злонамеренного... Более того - такое состояние обязательно когда-нибудь наступит.
А если не предпринимать специальных мер - то в конкурентной среде такое состояние может возникнуть и вполне себе штатно.
PS. Если записи с показанными состояниями строго зависимы и связаны один-к-одному, но создаются как независимые записи, то у Вас неверно проделан анализ предметной области, и как следствие - ошибочная схема данных.
Вы показываете два результата отдельных запросов с одинаковым набором значений поля user_id. Однако ничто не гарантирует одинаковости этих наборов. Каким должен быть объединённый результат в случае несовпадения наборов? покажите..
Импорт CSV в таблицу - он тоже требует запроса, причём с указанием всех полей поштучно. Если при конвертации JSON в CSV ещё как-то можно обеспечить детерминированный порядок полей в выходном файле, то вот ориентироваться на соответствие порядку полей в структуре таблицы - занятие крайне опасное. Самое простое, что может быть - изменение структуры таблицы в очередной версии, когда факт существования "дефолтного" экспорта подзабылся. И хорошо, если при этом просто перестанет работать - а если случайно импортируется, но не туда, потому что два поля поменялись местами? потом откатываться по данным всегда неудобно, и даже не всегда возможно. А ещё полученные от клиентов данные порой имеют неполный набор атрибутов, что тоже при неаккуратности может аукнуться. "Быстро, дёшево, качественно - выбери два из трёх" - очень актуальная штука.
Наверное, потому, что "от клиента получен JSON". А MySQL вполне в состоянии принять JSON, распарсить его и положить в таблицу.
Другой вопрос, что автору не хочется один раз поработать руками. Проще надеяться на то, что найдётся программа с единственной кнопкой "Сделать песдато".
Максим Припадчев, наверное, в том, что COPY - вот ни разу не от MySQL приблуда.. а так-то CSV и в MySQL запросто читается с помощью LOAD DATA - но зачем лишнее преобразование?
Впрочем, если версия MySQL достаточно свежая, то можно парсить на стороне MySQL функцией JSON_TABLE, а сам запрос построить динамически по списку атрибутов JSON и списку полей таблицы.
Например, полным перестроением дерева (фактически - копированием) в сортированном порядке в балансированную структуру (которая элементарно строится, даже заранее, на основании только количества узлов). Это будет не очень эффективно, но ничего в том невозможного нет.