[MySQL] Хранение большого числа записей

[pioneer]

Всем привет!
Есть следующая задача: организовать хранение SMS сообщений пользователей в таблице БД MySQL. В обозримом будущем предполагаемый объем равен пару тыс. сообщений в день, но эта цифра может увеличиваться (десятки, сотни, млн).
Как посоветуете организовать таблицу? Как индексировать? Не страшно ли переполнение по int(11) ID?
Буду благодарен за советы.

[pioneer]

Ответ: хранить ID в UNSIGNED BIGINT. Всем спасибо за помощь и ответы

[yiiliveext]

Ответ: хранить ID в UNSIGNED BIGINT. Всем спасибо за помощь и ответы

UUID тоже подойдет.

[skynin]

пару тыс. сообщений в день
Unsigned INT 4294967295
(4294967295 / 1000) / 365 = 11767 лет
1 млн каждый день - 11 лет
Не страшно ли переполнение по int(11) ID?

UNSIGNED BIGINT - будет обрабатываться как строка (в php нет безнакового типа для 64 битного int )
поэтому лучше Signed BIGINT если 11 лет - это мало.

(2^63-1) / 1 млн каждый день / 365 = 25269512430 лет

https://dev.mysql.com/doc/refman/8.0/en ... types.html

[pioneer]

Ответ: хранить ID в UNSIGNED BIGINT. Всем спасибо за помощь и ответы

UUID тоже подойдет.

Можно подробнее? Организовать хранение ID как varchar(36) и выставить на него INDEX?

[pioneer]

пару тыс. сообщений в день
Unsigned INT 4294967295
(4294967295 / 1000) / 365 = 11767 лет
1 млн каждый день - 11 лет
Не страшно ли переполнение по int(11) ID?

UNSIGNED BIGINT - будет обрабатываться как строка (в php нет безнакового типа для 64 битного int )
поэтому лучше Signed BIGINT если 11 лет - это мало.

(2^63-1) / 1 млн каждый день / 365 = 25269512430 лет

https://dev.mysql.com/doc/refman/8.0/en ... types.html

спасибо за арифметику) пожалуй вы правы, для начала и UNSIGNED INT будет достаточно, скорее я перегнул с BIGINT

[skynin]

Можно подробнее? Организовать хранение ID как varchar(36) и выставить на него INDEX?

Код: Выделить всё

yii\db\Schema::getColumnPhpType($column)

if ($column->type === 'bigint') {
                return PHP_INT_SIZE === 8 && !$column->unsigned ? 'integer' : 'string';