Допустим в качестве значений какого-то столбца нужно сохранить массив чисел.
Правильный "реляционный" путь — завести еще одну таблицу, у которой будет два столбца — ключ первой таблицы и одно из чисел массива.
Тупой путь для ленивых — если массив имеет фиксированную длину (скажем 3..4 элемента) то можно просто завести 3..4 столбца с именами типа item1, item2, item3, item4 и хранить эти числа там.

Но на самом деле: а почему нельзя хранить непосредственно массивы?
Строки — это массивы символов, и их можно хранить в MySQL. Причем как строки фиксированной длины, так и переменной. Для строк действуют специальные операторы, например LIKE. Мы же не заводим отдельно таблицу символов строки и не храним каждый символ отдельно? И дело не только в производительности, но и в логике. Иногда массив это не часть реляционной схемы, а "нечто целое и неделимое" — примерно как строка, и размазывать его по строкам другой таблицы нежелательно.

Понятно что есть блобы, а начиная с MySQL 5.7 есть тип столбца JSON, позволяющий сохранять структурированные деревья в формате JSON. Но JSON это достаточно навороченная структура данных... а все-же почему просто массивов нет (а заодно и структур)? Это ведь именно программисту по идее решать, что делать частью реляционной модели а что нет. А получается что СУБД принуждает к тому чтобы делать частью реляционной модели все до самого низкого уровня.