С каждым полем в таблице MySQL добавляет кучу служебных данных, да ещё и с выравниванием ...

1) не подскажите как хотя-бы примерно расчищать размеры данных на диске (даже при добавлении одинаковых строк размер изменяется нелинейно)?
2) Ка можно уменьшить размеры?
3) Может что-то полезное подскажите по этому поводу...?
Гуглил но нечего хорошего не нашёл... (было что-то про очистку -но у меня в основном только дополнение, сжатие тоже видел — но база активно пишется и читается...)

пробовал оптимизировать

mysql> optimize table molnia.messages;
+-----------------+----------+----------+-------------------------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+-----------------+----------+----------+-------------------------------------------------------------------+
| molnia.messages | optimize | note | Table does not support optimize, doing recreate + analyze instead |
| molnia.messages | optimize | status | OK |
+-----------------+----------+----------+-------------------------------------------------------------------+
2 rows in set (1 min 52.56 sec)

Из-за чего "Table does not support optimize, doing recreate + analyze instead"?
причём размер на диске увеличился...

Здравствуйте, VVVa, Вы писали:

VVV>2) Ка можно уменьшить размеры?

Общая цель какая? Сэкономить копейки на дисках?

Здравствуйте, wildwind, Вы писали:

W>Здравствуйте, VVVa, Вы писали:

VVV>>2) Ка можно уменьшить размеры?

W>Общая цель какая? Сэкономить копейки на дисках?

вобще-то да, там за 100Tb переваливает

Здравствуйте, VVVa, Вы писали:

VVV> Из-за чего "Table does not support optimize, doing recreate + analyze instead"?

For InnoDB tables, OPTIMIZE TABLE is mapped to ALTER TABLE ... FORCE, which rebuilds the table to update index statistics and free unused space in the clustered index.

Но при выключенном old_alter_table он может использовать оптимизированную версию, которая может не дать тебе нужного эффекта. В этом случае имеет смысл дропнуть индексы, перелить данные во временную таблицу, создать индексы, переименовать таблицу обратно.

VVV> причём размер на диске увеличился...

innodb_file_per_table включен же? Дальше можно попробовать поиграть с размером страницы innodb_page_size и/или innodb_fill_factor.

Но размер в 100TB и вставка в середину индекса кажется делает всю эту затею не особо разумной.

Здравствуйте, Anton Batenev, Вы писали:

AB>Но размер в 100TB и вставка в середину индекса кажется делает всю эту затею не особо разумной.

!!! интересная ситуация!!!
у меня вставок не будет. Но что будет с производительностью в этом случае?

Здравствуйте, VVVa, Вы писали:

VVV>вобще-то да, там за 100Tb переваливает

И все данные нужны? Или большая часть лежит "мертвым грузом" (в смысле обращаются раз в год или реже)?

Здравствуйте, VVVa, Вы писали:

VVV> AB>Но размер в 100TB и вставка в середину индекса кажется делает всю эту затею не особо разумной.
VVV> у меня вставок не будет. Но что будет с производительностью в этом случае?

Если вставок не будет, то производительность в основном будет зависеть от того, какой процент горячих данных находится в памяти (innodb_buffer_pool_size). Но в общем случае это очень обширная тема (тем более для таких объемов).

Здравствуйте, wildwind, Вы писали:

W>Здравствуйте, VVVa, Вы писали:

VVV>>вобще-то да, там за 100Tb переваливает

W>И все данные нужны? Или большая часть лежит "мертвым грузом" (в смысле обращаются раз в год или реже)?

Да именно пару раз в год...
Но заказчик хочет чтобы при этом (в эти пару раз в год) данные были в MySQL или M$SQL