Как быстрее подсчитать пересечение в таблице?

Требуется вывести для каждого слова, набор слов с которым оно встречается(пересекается) в строке, с выводом количества таких встреч(пересечений).

Вот первое, что хочется спросить - Вы вообще себе представляете объём вывода? 10кк уникальных слов формируют 100 триллионов пар. И к каждой надо посчитать количество. Да даже если представить, что уже всё посчитано, и надо только вывести - оно ж выводиться будет неделю! да ещё надо найти такое хранилище, в которое это можно вывести - тут о сотнях терабайт речь...

Ну а вообще - грузим в БД, нормализуем, индексируем да считаем что нужно. Тривиальная в общем задача.

Как сохранить целостность данных?

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

У Вас такого обоснования нет даже приблизительно. Так что все первичные ключи - только синтетика. А на данные можно накладывать всякие NOT NULL и создавать уникальные композитные индексы в соответствии с требованиями предметной области.

как сделать в SQL, уникальными номер бирки в рамках одной фермы

Это называется "композитный индекс".

Mysql, как выполнять события(events) только при условии?

Миша,

А при вызове этого запроса запрос в конфиг будет вызван один раз или для каждой обновляемой строки будет проверяться?

Запрос некоррелированный, независимый - он будет выполнен однократно.

Mysql, как выполнять события(events) только при условии?

BEGIN-END отсутствует.

Поэтому всё до первой точки с запятой воспринимается как запрос на создание эвента, а финальный END IF; - как "висящий в воздухе" непонятно к чему прилепленный обрывок.

Как получить несколько записей из связанной таблице?

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

Как получить несколько записей из связанной таблице?

Покажите исходные данные как CREATE TABLE + INSERT INTO, и требуемый результат для них.

Как в подзапросе сделать группировку?

Делайте fiddle или хотя бы выкладывайте необходимый код (CREATE TABLE + INSERT INTO + проблемный запрос и требуемый результат).

Как в подзапросе сделать группировку?

Это подзапрос в списке вывода? Убрать GROUP BY но добавить коррелирующее условие во WHERE.
Или вообще переместить это подзапрос во FROM с соотв. условием связывания.

Как сделать чтобы строка не вставлялась в БД, если не соблюдается формат поля?

т.е. я не прав, вы все таки описываете, что есть бек-приложение на сервере, которое общается с базой, и к которому обращается клиент с фронта?

Я вообще не рассматриваю то, что находится за пределами соединения (connection) между MySQL-сервером и обращающимся к нему клиентом. Я говорю только и исключительно о приложении, которое посылает SQL-запросы и получает обратно результаты их выполнения, и сервере, обрабатывающим эти запросы. Всё. За пределами этого процесса пусть происходит что угодно, какие угодно валидации и протчая.

полностью перенести в нее бизнес-логику по валидации проблематично:

Это всего лишь очевидные недостатки используемых инструментов. Почему логика на стороне СУБД столь проблемна? Что, там нельзя все описанные операции проводить? да можно! только инструментов для этого никто не делает, ограничиваясь средствами на стороне фреймворка, типа этого достаточно. Ну да, достаточно... А что при этом микроскопом гвозди забиваем - какая ерунда! Гвоздь забит? забит... всё, задача решена.

Как сделать чтобы строка не вставлялась в БД, если не соблюдается формат поля?

Vitsliputsli, возможно. В той схеме, которую Вы видите в позиции DevMan, я описываю взаимодействие бэк-приложения с СУБД.

Как сделать чтобы строка не вставлялась в БД, если не соблюдается формат поля?

DevMan, это комментарий к Вашему ответу - Вы должны были получить о нём уведомление, если ранее явно не отключили их.

Как сделать чтобы строка не вставлялась в БД, если не соблюдается формат поля?

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

Как сделать чтобы строка не вставлялась в БД, если не соблюдается формат поля?

DevMan, БД ничего не создаёт, она хранит то, что даёт приложение. Ей негде и не в чем ошибиться. Это юзер может ввести не ту букву или импортировать не тот файл.
Если данные косые - это приложение их подало косыми, потому что либо это стороннее приложение, либо проверка такого типа косины не предусмотрено валидацией. Либо программист не ту БД сделал текущей. И не вижу ничего плохого в том, что СУБД эту косину обнаружит.

Как сделать чтобы строка не вставлялась в БД, если не соблюдается формат поля?

DevMan,

кстати, если не верите валидации приложением, откуда уверенность в валидации базой?

Ну тут ответ как бы очевиден. Валидация приложения может быть сама по себе написана неверно или неполно и не учитывать какие-то особые сочетания. А вот вычислениям при валидации я как раз верю - если два плюс два получилось четыре, то это правильный результат, что в приложении, что в СУБД. Пять - никогда не получится.

Как сделать массовое обновление записей в mysql?

rinaz22,

Есть какие-либо ограничения по количеству SELECT внутри?

Нет.
Есть только ограничение на размер входящего пакета.

Но если количество значений большое (ну где-то от 10 тысяч и более), то лучше передавать сериализованный массив значений (CSV, JSON) и парсить его в запросе.

Как сделать массовое обновление записей в mysql?

rinaz22,

Например если нужно обновить 100 записей, сколько всего будет SELECT?

В CTE - сто. Но запрос-то всё равно один. Ну и скалярный запрос без источника данных (это SELECT-ы в CTE) - штука быстрая.

при использовании этого запроса, возникает ошибка на UPDATE после ')'

Ну где-то косячишь, значит. https://dbfiddle.uk/?rdbms=mysql_8.0&fiddle=e0d6b5...

Как сделать массовое обновление записей в mysql?

rinaz22,

чем отличается этот запрос от одиночных запросов?

Это - один запрос. Который один раз передаётся на сервер, один раз парсится, для которого один раз создаётся план запроса. Но обновляет он сразу все записи.

Я так понял, будет столько же SELECT, сколько записей нужно обновить?

Неправильно понял.

Как сделать чтобы строка не вставлялась в БД, если не соблюдается формат поля?

DevMan,

что мешает приложению отправить валидные данные или сделать отбой?

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

Валидация на стороне сервера БД - гораздо более надёжная процедура. Хотя бы потому, что этот процесс прошёл гораздо больше проверок, чем любое клиентское приложение. Я сейчас имею в виду не валидацию в виде хранимых процедур - там код опять же пишет программист, который не идеален. Речь о встроенных валидациях - ограничения типов, NOT NULL, внешние ключи, уникальность... и эти валидации не зависят от приложения - вообще.

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

Как сделать чтобы строка не вставлялась в БД, если не соблюдается формат поля?

DevMan, повторю:

Данные должны проверяться как клиентом, так и СУБД.

Вот как, КАК? Как это можно интерпретировать, что приложение-клиент НЕ валидирует данные? Нет, ну как?

Как сделать чтобы строка не вставлялась в БД, если не соблюдается формат поля?

DevMan, так это приложение и есть клиент.