ThunderCat, так именно в этом и состоит вопрос: стоит ли убирать первичный ключ с char(32) и даст ли это прирост скорости на вставку? Потому что просто так сломать продакшн и потратить время на переделку всей базы я не могу.
Потому что по тестам выходит, что вроде бы да.
А по ответам выходит, что не должно.
ThunderCat, > что заставило создавать именно чаровый ключ, еще и с такой длиной
Такие данные приходят из внешнего источника, и по этому ключу они дальше связываются с другими (и у меня, и в источнике) - поэтому пришлось плясать вокруг него.
А первичным ключом он стал 5 лет назад, когда в таблице было 900 тыс. строк и никто не думал, что она вырастет в 100 раз.
> объем данных в тестовой бд меньше, и соответственно тупо индексы перестраиваются быстрее
Данных там действительно меньше (в ~10 раз), но я же тестировал её в обоих вариантах: с ключом char(32) и с ключом int auto increment.
Выглядит действительно так:
show table status
показывает размер индекса в 17,8 ГБ, при том чтоinnodb_buffer_pool_size = 15G
.То есть, тут два варианта:
1. либо докинуть ОЗУ;
2. либо уменьшить индекс, правильно?