MySQL как кнопка таблица оптимизация ID auto_increment

Question

У меня есть эта таблица:

CREATE TABLE IF NOT EXISTS `likes` (
    `id` int(11) NOT NULL AUTO_INCREMENT, 
    `user` varchar(40) NOT NULL, 
    `post_id` int(11) NOT NULL, 
    PRIMARY KEY (`id`) 
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ; 

это для большого магазина, это позволит клиентам нравятся продукты. он записывает, кто нравится (пользователь) и что (сообщение id). подобный facebook.

например: 1 - мария - 233 2 - джон - 527 ...

так, как 1, 1 запись.

Как я могу его оптимизировать? разрешить многие записи? и быть как можно быстрее?

Могу ли я использовать KEY Partitioning? любой пример этого? что относительно id int (11) слишком мало?

большое спасибо!

Answer 1

INT, по умолчанию SIGNED; диапазон от -2 млрд до +2 млрд. Он занимает 4 байта. Но AUTO_INCREMENTs никогда не будут отрицательными, поэтому INT UNSIGNED будет лучше - от 0 до + 4 миллиардов (и еще 4 байта).

4 миллиарда - это более половины населения мира. Если вы приближаетесь к этому числу «любит», кто-то обманывает, и вы должны подключить это отверстие.

Ditto for post_id. И user_id. (Ой, я опережаю себя.)

пользователь VARCHAR (40) CHARACTER SET latin1 - Если вы надеетесь получить даже отдаленно близкое к 4 миллиардам, вам нужно позволить китайцам, тайцам, корейцам и т. Д. , in. Используйте utf8mb4.

Нужны ли вам пользователи для регистрации? (В противном случае, как вы можете помешать кому-либо «набивать урну для голосования»?) У вас есть другая таблица под названием Users? И у него есть AUTO_INCREMENT? И этот id является 4-байтным INT UNSIGNED? Итак, не используйте здесь полное имя; используйте этот идентификатор. Меньше -> больше cacheable -> меньше ввода-вывода -> быстрее.

PARTITION? Нет. Не используйте PARTITIONING, не понимая, что мало он может сделать и сколько он не может сделать. Он не обеспечивает скорость; конечно нет для этого использование случай.

ДВИГАТЕЛЬ = MyISAM. У вас когда-либо была сбой питания на сервере с таблицей MyISAM на миллиард строк? Когда сервер выполняет резервное копирование, он начинает жаловаться на поврежденную таблицу. Вы проводите несколько часов, выясняя, что это значит. Затем вы запустите REPAIR TABLE. Через несколько часов заканчивается. Между тем система недоступна. Используйте ENGINE = InnoDB.