Следующая задача:
Требуется использовать циклическую таблицу в БД реального времени.
Структура таблицы:

CREATE TABLE T1(
I int unsigned default NULL,
D int64 default NULL,
V float default NULL,
F tinyint default NULL,
PRIMARY KEY (I),UNIQUE (D))

Кол-во записей 10000000 (I=1,2..10000000).
I D V F
1 11554565888 121.21 0
2 11554565889 121.56 0
3 11554565890 122.35 0
4 11554565891 133.77 1
.
.
10000000 12554565888 110.55 0

Обновление данных осуществляется по индексному столбцу I, при том столбец I не изменяется (создаются данные только при инициализации таблицы данными).
Выборка данных ведется по столбцу D.

Суть вопроса в том, как будет изменяться размер индексного файла при выполнении запроса UPDATE типа:
UPDATE SET D=11655695768, V=135.75, F=0 WHERE I=376548
UPDATE SET D=11655695769, V=134.22, F=0 WHERE I=376549

ВОПРОС: Какое поведение ждать от файла индекса?
Циклическая запись выполняется с целью не блокирования файла таблицы на длительное время при таких операциях, как Delete.

Каким образом можно использовать индекс, чтобы в принципе избежать изменения размера индексного файла при операциях UPDATE.

Не будет ли индексный файл увеличиваться до 2 GB?

Просьба ответить.

Спасибо за ответ.

Да как раз я имею в виду поле D.
Скорее всего, только тестом можно будет узнать.
На поле D распространяется так называемая деградация данных, судя по книге MySQL.

Спасибо за ответ.

Система используется для промышленного архива.
Записывается приблизительно 500 каналов в секунду (500 таблиц).

Сейчас эксплуатируются не цикличные таблицы, это налагает большие издержки на обращение к жесткому диску.
Целью является повышение надежности хранения архива за счет снижения обращение к жесткому диску.
К тому же на операции удаления избыточных данных уходит большое количество ресурсов и времени (блокируются таблицы).