если вам нужно иметь данные отсортированные по c_id указывайте в выборке `order by c_id`
наличие индексов само по себе не определяет порядок сортировки при выборке.
вносятся данные с сортировкой по tag_id (он же primary key), а надо по c_id.
данные вносятся и хранятся безо всяких сортировок. если вы пишете без удалений, то данные будут лежать в естественном порядке записи , если с удалениями - тут уже никто не знает что будет
то что у тебя - это данные UTF-8 которые отображаются как 1251. т.е. например ты взял файл в UTF-8 и прочитал его как 8-ми битный. либо отправляешь в MySQL данные UTF-8 но говоришь при этом что они 8-ми битные.
если к теоретическим "нормальным фомам" - это одно
если к скорости выборки - это другое
если к объемам хранимых данных - это третье
например на скорость будут влиять - какой диск, какая б/д, какие таблицы, какие доступны лимиты по памяти, по процессору.
20 - это не огромное значение. вот когда их 200 или 2000 ... нужно смотреть на определенность этих параметров, на их дублирование. если они все определены - тогда эффективнее (с любой точки зрения) их хранить в одной таблице, если из 20 заданы 5 - тогда разбивать на сущность/атрибуты/значения (я бы так поступил).
опять же - если параметры неизменяемы и по ним нет выборки - может их эффективнее хранить в одном поле в JSON ?
в общем все очень индивидуально относительно конкретной задачи и универсального рецепта нет.
а конкретно в случае бд недвиги я бы пошел таким путем
1) таблица объектов (тип объекта, тип сделки аренда/продажа)
2) таблицы параметров по каждому типу объектов
3) таблицы параметров по каждому типу сделок