Из чего кстати можно сделать вывод, что для часто меняющихся строк может быть разумнее использовать char, вместо varchar. Оверхэд с занимаемым местом будет и там и там, но в случае с char не потребуется расщеплять страницу.
Т.е., допустим, таблица - файл .ibd. В строке пишем в varchar 'qwe', следом там другие поля. Потом решили обновить varchar, более длинным текстом, чем сейчас, но просто так его вписать нельзя - перезапишем следующее поле
Хотя рано отметил решением. Мне бы больше технической инфы.
Например, у меня 80 тыс строк. Там, по-мимо int, ещё 4 поля varchar(255), что уже должно давать 80000 * 4 * 255 = 80Мб минимум. Хотя на деле, менее 50Мб.
Либо под "резервировать место" тут понимается не то же самое, что в файловых системах, тогда не ясно, чем такая резервация отличается от описания фрагментации в моём вопросе.
Spartak (Web-StyleStudio), есть традиция на тостере такая - не внимательно читать вопросы.
Вопрос о том, как корректно через popen записать через stdin в gzip, что бы потом корректно прочитать сжатые данные из stdout
Опечатался. Вопрос не про gzip с несуществующей опцией папки, а tar с опцией сжатия, конечно же (хотя догадаться не сложно, по-моему).
Вобщем, ответ найдет. Сжатие происходит так: файл пишется сразу сжатым. Итого, нужно места столько, сколько может занять сжатая папка.
Такое представление в БД занимает меньше места, и индексы быстрее.
Но вот насколько это снижает надёжность в плане коллизий - не понятно.
Понятное дело, что sha1 - хорошо, а sha256 - ещё лучше, но, вполне может быть, что такая надёжность избыточна.
