Akina

Простейшим вариантом будет выгрузить csv и, соответственно, загрузить его в mysql, используя либо запрос LOAD DATA либо какую-нибудь кнопочку в интерфейсе.
Во всяком случае, на этот вариант вы потратите гораздо меньше времени, чем на поиски "экранирования".

А так-то SQL сервер вряд ли поддерживает создание дампа в формате Mysql напрямую

В общем, чтобы не издеваться над девушкой, объясним на пальцах.

Во-первых, заголовок у вопроса чудовищно некорректный. Это все равно что спросить, "что быстрее - пылесос или стиральная машина?"
Во-вторых, ответ на вопрос "производить ли обработку данных в БД или же запросить все данные в клиентское приложение и обрабатывать там" совершенно очевиден: обработку данных следует производить в общем случае только в БД. Она для этого и придумана. Чтобы обрабатывать значительные объемы данных.

Да, js тоже "может" обрабатывать большие объемы данных.
Но чтобы значительный объем данных обработать, его сначала надо передать, полностью забив канал между сайтом и базой
Чтобы значительный объем данных обработать, его надо сначала проиндексировать. Причем делать это каждый раз, а не использовать уже имеющийся набор индексов
Чтобы значительный объем данных обработать, надо иметь значительный объем памяти или упасть из-за её недостатка
Чтобы значительный объем данных обработать в многопоточном режиме (а сайт как раз является многопоточной системой), все вышеперечисленное надо умножить на количество посетителей сайта - при каждом запросе перегонять весь массив данных, выделять память, индексировать, считать. Если же вы оставляете все данные в памяти приложения, то их тогда надо как-то синхронизировать с БД. То есть вы себе собираете кучу проблем на пустом месте.

Несомненно, из любого правила есть исключения. И бывают ситуации, когда приходится считать в приложении.
Но на вопрос в общем виде ответ будет совершенно однозначный. Не "может так, может сяк", а только в БД.

Andrew_Novikov,

Пользователь выбирает имя спортсмена, например "Petr_Yan", дальше идет запрос к БД "select * from Petr_Yan",

нет-нет дружище так нельзя. Переделывай. Никто не создает по таблице на пользовательский
запрос. Таблица - слишком дорогой ресурс чтобы ей так просто бросаться.

Над таблицами думают. Их рисуют на архитектурных диаграммах. Ты чисто случайно словил
дефект в различиях файловых систем Linux/Windows и мы пришли вообще к тому что ты
сделал невернй дизайн БД.

После того как переделаешь - проблема сама собой уйдет. А когда будешь придумывать
имена таблиц - делай все в одном регистре. Так - проще жить. Меньше в будущем
будет архитектурных косяков.

x * y = 4608000
x² + y² = [6.73 * 522]² = 12341169

y = 4608000 / x
x² + 4608000² / x² = 12341169

x⁴ - 12341169 * x² + 21233664000000 = 0
D = 12341169² - 4 * 21233664000000 = 67369796286561
x² = (12341169 + sqrt(D)) / 2 = 10274539
x = 3205.392, y = 1437.578

Дальше можно посмотреть ближайшие стандартные разрешения и выбрать подходящее.

Обычно поднимают балансировщик и делают так что сначала все ходят на 1.1.1.1.
Потом делают перевод новых сессий в новое место в пропорции 20:80.
И так далее пока все сессии не переползут.

SET `datetime` = GREATEST(`datetime`, NOW()) + INTERVAL 10 DAY
  WHERE ...

Естественно, поле должно быть стандартного типа DATE или DATETIME.

Похоже Вам нужен UNION

select 't1', phone           from t1 where phone = '987654321'
union all select 't2', phone from t2 where phone = '987654321'
union all select 't3', phone from t3 where phone = '987654321'

https://sqlize.online/sql/psql14/ac0b0a66662794d8c...

Из поисковых систем для Full-text search я помню только две. Sphinx, Lucene (на его базе Elastic/Solr). Но насколько они применимы в данном примере - я не знаю. Надо глубже понимать задание. На уровне юз-кейсов.

Зачем тут графовая БД - непонятно. Приведите пример что вы хотите записывать в граф.

Надо, чтобы "четность" перестановки совпадала с четностью финального поля (1).
Занумеруйте все 16 позиций слева направо сверху вниз.
чтобы подсчитать четность, рассматривайте каждую пару заполненных позиций (15\*14/2=105 пар) - если числа идут не в том порядке (большее число на позиции с меньшим номером) - то прибавьте 1 к ответу. В конце возьмите ответ по модулю 2. Это и будет четность перестановки.

Чтобы получить поле, которое можно собрать, сгенерируйте любую перестановку (случайно перемешайте 15 чисел), а потом посчитайте ee четность. Если четность плохая, то поменйте местами любые 2 соседних элемента (выберите случайно, или меняйте первые 2 всегда - на вероятности всех возможных полей это не влияет).

Edit: Но вы это почти все итак знатете, ибо функция is_solvable в вашем коде как раз инверсии уже считает.
Значит, Но вы знаете, что плохое поле от хорошего отличается лишь четностью, значит, если поле плохое - меняйте местами 2 соседних по порядку элемента. Например верхний левый со вторым в верхней строке.

Как всегда автор не указывает тип dbms. Ох-ох-ох..

Запрос состоит из двух функционалов. Один - это собственно выборка - и другой это вставка.
Скорее всего медленно работает выборка в части соединения двух таблиц.

INSERT INTO tabel0 (row_1, row_2, row_3, row_4)
SELECT oa.row_5,
       oa.row_6,
       oa.row_7,
       nw.row_8
FROM table1 t1
       LEFT JOIN table2 t2 on t2.row_9 = t1.row_10
WHERE t2.row_11 IS NOT NULL;

Вот здесь где идет join по row_9 и row_10 надо построить индексы по этим полям.
Потом прогнать analyze по обоим таблицам.

И запустить еще раз.

Вставка тоже может тормозить по разным условиям (триггеры, instead-of триггеры, сложные констрейнты
или просто сложные типы данных наподобие xml/json которые требуют много I/O). Но для начала
надо хотя-бы с выборкой разобраться.