Иван Мельников

For MySQL:

CREATE TABLE `order` (
`id` MEDIUMINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
`city_id` SMALLINT UNSIGNED NOT NULL,
FOREIGN KEY (`city_id`) REFERNCES `city` (`id`)
);

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

Начнем с того, что ваш ответ неверен.
На первое место в слове мы можем выбрать любую из 33 букв.
На второе место, мы можем поставить какую-то из 32 букв (повторять соседнюю букву нельзя!).
На третье место также можем поставить одну из 32 букв.
На четвертое и пятое место аналогично.
Согласно комбинаторному правилу умножения, кол-во разных 5-буквенных слов равно 33*32*32*32*32 = 33*32^4.

MySQL Workbench 8.0.

ИМХО, работа на дому ведет к деградации коммуникативных навыков. В результате, вы отрезаете себе путь развития в плане управления людьми и процессами, а следовательно, и в плане продвижения по карьерной лестнице.

Либо из txt, либо из mysql. Необходимо удалить все дубли. То есть не оставлять одинаковых строк вообще.

В MySQL в рамках одной таблицы двух одинаковых строк не может быть по определению реляционного отношения.
Если имеются в виду дубли по множеству полей, то как вариант:

DELETE FROM 'table' WHERE concat_ws('', 'field1', 'field2') IN
(SELECT `a` FROM (SELECT concat_ws('', 'field1', 'field2') `a`
FROM 'table' GROUP BY 'field1', 'field2' HAVING count(*) > 1) 'x')

Однако, строки

... field1  |  field2 ...
    NULL    |  'ivanov'
    ''      |  'ivanov'

будут восприниматься как дубли друг друга и будут удалены обе.

А почему вообще возникла идея сохранять данные куда-то, а не крутить ими прямо в БД? Во что вы уперлись?

SELECT * FROM `number_1` WHERE concat(`field_1`, ' ', `field_2`, ' ', ..., ' ', `field_n`) LIKE '%13%'

но почему то он выдаёт в данном случае Южно-Сахалинск, хотя должен Улан-Удэ

С чего бы это? Строки сравниваются лексикографически: 'Южно-Сахалинск' > 'Улан-Удэ'.
Подсказка:

print(ord('Ю'))
print(ord('У'))
_____________
1070
1059

Кол-во элементов списка ограничивается только доступным объемом ОЗУ.
Допустим у вас 32-битная ОС.
Список, в отличие от массива, устроен таким образом, что в самом списке хранятся только адреса (из 32-битного адресного пространства) расположения самих данных. При этом, хранить в памяти нужно и адреса (элементы списка), и сами данные.
Так вот, при создании списка, например, с 2,147,483,647 элементами только для хранения элементов списка (адресов) потребуется не менее 2,147,483,647 x 32 = 68,719,476,736 бит памяти, или 8,589,934,592 байт = 8 ГБ.
А ведь ещё нужно хранить сами данные. И не нужно забывать, что запущенный софт на машине тоже требует для своей работы память.
ps. Массивы гораздо эффективнее используют память, но есть ограничение – все элементы массива имеют единый заранее определенный тип.

Как насчет модели управления доступом на основе ролей (RBAC) ?
Такие сущности, как ресурс, действие, пользователь и роль выделяются в отдельные отношения. Связываются они табличками вида M:N.

SELECT `node1`, count(`node1`) FROM `table` GROUP BY `node1`

Теперь правильный вариант:

SELECT `node1`, count(*) FROM
(SELECT `node1` FROM `table` UNION ALL SELECT `node2` FROM `table`) AS T
GROUP BY `node1`

Проверил, работает как нужно.

Ну вот вообще не вижу и не понимаю причин хранить целые числа (включая хэш-суммы и ip-адреса) в VARCHAR-ах. Целочисленные типы и были придуманы для того, чтобы хранить в них целые числа.
Например, возьмем 15-значное целое число в десятичной системе счисления. Если вы выберете для его хранения тип VARCHAR(15), то одно значение будет занимать 15 байт + 1 байт = 16 байт.
При этом тип BIGINT UNSIGNED весит всего 8 байт и имеет диапазон значений от 0 до 18446744073709551615 (включительно). Как следствие, скорость поиска, сортировки, сравнения, добавления новой записи будет выше.