Akina

При попытки создать mysqldump база выдаёт ошибку:
Illegal mix of collations (utf8_unicode_ci,COERCIBLE) and (utf8_general_ci,COERCIBLE) for operation 'locate'

Скорректируйте @@collation_connection.

Задача сделать копию битой БД mysql ... как из файлов "холодного резерва" создать sql-файл или как эту базу развернуть на другом сервере mysql?

А смысл? если подключить файлы данных в новом местоположении, ошибки никуда не денутся.

А так - создать таблицы в новом местоположении. Структура должна совпадать с точностью до запятых, и версия сервера тоже. Самое разумное - сделать бэкап чисто структуры, без данных, и развернуть. А потом DISCARD/IMPORT TABLESPACE, либо замена файлов при остановленном сервисе и последующий запуск с лечением и перезаписью метаданных и статистики.

Не стреляйте в пианиста - он играет как умеет.

Ну что вы так сразу все набросились-то? Придурок писал, увольняйся нафиг... Вопрос совершенно чётко утверждает, что программа, созданная инициативно, полностью готова и корректно выполняет всё в неё заложенное - так что создавший её как бы не совсем придурок-то. А то, что руководство требует её развивать, однозначно говорит, что она ещё и полезна.

Как я понимаю, программа эта выполняется локально и монопольно, вряд ли многопоточная, и даже допускаю, что не разрешающая одновременного запуска нескольких инстансов (хотя вот это уже совсем предположение). А потому не вижу никаких противнопоказаний к нормальному рефакторингу и получению в конечном итоге приложения, сохранившего весь функционал, но написанного "по науке".

Сейчас главное - полностью разобраться в том, что и как программа делает, и просто понять, что будет дешевле - модифицировать программу или, при сохранении текущей версии и используя её как основу, написать новую версию с нуля.

Армянское Радио

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

Такие программы сплошь и рядом начинаются как маленькие приблуды, создаваемые одним работником для себя, для облегчения своей работы и снятия с себя тупой рутины. И работодатель тут вообще никаким боком - он не поручал и не заказывал, оно само родилось. И тут уж как работник смог, так и сделал. И то, что программа не просто работает, но и полезна настолько, что принято решение её развивать и это развитие оплачивать - так это работнику жирный плюс.

Порядок выполнения запроса может не совпадать с его текстом.

А вот с планом он совпадает на 100% - ну просто потому что выполняется именно по этому плану.

Как сменить пользователя в MySQL?

В текущем соединении - никак. Только (закрыть это и) создать новое соединение, с использованием другой учётной записи.

В чем тогда проблема для провайдера просто блокировать все зашифрованные запросы?

Это противоречит действующему законодательству. См. законы о предоставлении услуг связи и о предоставлении телематических услуг.

Провайдер может блокировать трафик только в случае, когда он чётко знает, что данный трафик должен блокироваться. Блокировать всё подряд выглядящее подозрительным - путь, в конце которого можно найти лишение лицензии. А если и нет - то всё равно большую кучу проблем. Поэтому провайдер будет соблюдать именно букву, а не дух.

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

В комментариях дампа указано, что источником дампа послужил сервер MySQL версии 8.0.28. Поэтому восстанавливать следует на сервере MySQL, причём крайне желательно на версии не ниже 8.0.4. При восстановлении на более младшей версии или на частично совместимой MariaDB возможны проблемы при восстановлении, которые потребуют ручной корректировки дампа - а для этого нужны определённые знания, которых, скорее всего, нет.

Для восстановления на локальном MySQL-сервере самое разумное - загрузить клиент командной строки и в нём:

• создать новую БД (CREATE DATABASE databasename;) (в комментариях дампа указано имя history_futures_binance, так что разумно использовать именно его, если такой БД на сервере нет)
  
• сделать её текущей (USE databasename)
  
• дать команду на развёртывание дампаSOURCE 'x:\path\filename.sql'.
  

Скорее всего, всё будет выполнено без ошибок, и в результате БД будет восстановлена. Если же при выполнении возникнут проблемы, будет выведено какое-то сообщение об ошибке - и в зависимости от него нужно будет предпринимать какие-то корректирующие действия.

Вот нафига было удалять предыдущую версию вопроса?

Ладно, повторю. У FileSystemObject нет метода Copy, он есть у объектов Folder и File. Следовательно,

Set File = fso.GetFile(ThisWorkbook.Path & "\doc.docm")
Set File = fso File.Copy("%Temp%\d6c.docm")

PS. Что такое "открытый файл", где, кем и вообще почему он открытый - так и не понял.

1. На проблемном сервере:
   
   • Создать папки баз.
     
   • Запустить сервер в режиме восстановления (InnoDB Recovery Modes).
     
   • Дропнуть базы.
     
   
   
2. Если не удаётся запуститься даже в режиме восстановления:
   
   • Восстановить БД из бэкапа на другом инстансе сервера
     
   • Скопировать каталоги баз на проблемный сервер
     
   • См. п. 1.
     
   
   

n_flag может быть 0..5
num_status 0..20
...
запись, где n_flag=0 и num_status>=10.

Указанным условиям при равномерном распределении значений соответствует ~9% записей, т.е. 18 млн. Причём отбор по n_flag более селективен.
Чисто теоретически оптимальным без использования фич Постгресса будет индекс (n_flag, update_date, num_status).

DEMO fiddle. Правда, 200 млн. записей я генерить как-то не решился... но для 1 млн. записей запрос показывает 40-50 мс - по-моему, вменяемо.

PS. Индекс называется на "комплексный", а композитный. Кроме того, этот индекс - покрывающий, т.е. для обработки запроса серверу не требуется обращаться к таблице.

Начните с формализации данных. Хотя бы введите единообразие наименований (наименование должно выбираться из списка, а не вводиться в свободной форме, либо должна заполняться форма со всеми возможными наименованиями) и формата представления данных. Это задача 1.
Задача 2 - решить, в каком виде будет заполняться ежедневная форма. Веб-форма тут в общем вполне подойдёт. На гугле свет клином не сошёлся - есть те же яндекс-документы, например...
Задача 3 - передача готовой формы. Тут я бы рекомендовал выгрузку в локальный CSV и отправку по электронной почте. Это контролируемый и протоколируемый канал, бесполезно говорить, что письмо было отправлено вовремя, если его нет в отправленных или если дата отправки - безнадёжно просроченная.
Задача 4 - загрузка полученных данных в единое хранилище. Тут уже можно думать о приличной СУБД. Ну а её штатных клиентских средств для загрузки - за глаза.
Задача 5 - аналитика. Имея данные в БД, получать аналитику в любых формах и разрезах - не проблема.
Ну и задача 6 - формирование красивых выходных документов с результатами анализа. Тоже не сказать что проблема.

Можно ли написать такой же запрос, если поле raw не jsonb, а text?

Ну офигеть проблема - заменить tp."raw"->>'errorCode' на tp."raw"::JSONB->>'errorCode'

Кстати, это применимо к полю обоих типов. Просто для JSON - избыточно.

Трассировка - это ICMP. Обработка ICMP, или во всяком случае обработка ping и отправка pong - это задача с низшим приоритетом для любого узла за редчайшим исключением. Потому даже 100% потерь ни о чём не говорят. TCP или UDP пинг был бы более информативен, но с ними есть определённые сложности - при отсутствии специального ПО на целевом узле результаты будут весьма приблизительными.

Потери на промежуточных узлах тоже ни о чём не говорят. Во-первых, маршрутизаторам и без ответов на твои пинги есть чем заняться, во-вторых, тебе с промежуточными узлами общаться не требуется. ДО целевого узла добирается всё? и даже ответы - тоже возвращаются все? ну и славненько. Вот время прохождения пакета - это значимое число. Да и то, с учётом низкого приоритета, прохождение TCP пакета может быть намного быстрее.