Однако, если вы работаете с кириллицей и вам реально надо однобайтовую кодировку, при использовании юникода взамен generated columns (не очень удобны, но не так уж неудобны) база может распухнуть куда больше (это зависит от процента кириллических символов и по каким колонкам регистронезависимый поиск реально нужен). В самом деле,

1) (экстремальный случай) Если у вас исходная колонка CHAR(X) и в ней только русские символы, в юникодной базе она должна быть CHAR(2X) и размер индекса удваивается (точнее, конечно, удваиваются размеры значений в нём). Возможно, регистронезависимый поиск по ней не нужен. А если нужен, то в однобайтовой базе вместо одной колонки CHAR(2X) будет две CHAR(X), но индекс будет по одной, меньшего размера (имея в виду, что мы делаем его по uppercase'вой колонке).

2) (другой экстремальный случай) С другой стороны, пусть возьмём две колонки VARCHAR(X) (вторая - generated, ucase от первой) и эквивалент - одну VARCHAR(2X) в юникодной. Для русской строки в N байтов в таблице однобайтовой базы потребуется 2*N байтов плюс два VARCHAR-оверхеда. Для юникодной будет один VARCHAR-оверхед вместо двух, но размер ключа в индексе удвоенный. Для латинской же юникодная база однозначно должна быть выгоднее.

Для конкретных случаев надо считать.