Дмитрий Шицков, > Использование его как составного pk не думаю что как-то изменит производительность запросов
По опыту - начиная с сотен миллионов записей случайный (в кортеже - два хеша мд5) первичный ключ даёт огромные замедления при вставке.
И решение - сделать ключ unique, а на primary поставить auto increment - как бы тупо и странно оно не звучало - работает, и вставка становится нормальной.
Я не знаю, как и почему это работает, но на практике проверено не раз.
Там большой CSV на 3 млн строк, который обновляется каждый день. Этот дамп скачивается и закидывается в базу. Какие из записей совсем новые, какие изменились, какие нет - неизвестно - поэтому мне показалось самым простым решением делать именно on duplicate key update.
Строки бьются пачками по 1000 штук и заливаются одним большим INSERT INTO values ( ... ), ( ... ), ... - соответственно проверять наличие строк перед вставкой и/или обновлят через update не получится.
По этой же причине не катит и replace - который ещё медленнее и при этом обновляет счетчик в auto increment.
> Там действительно в основном новые данные (с новыми tuple_first, tuple_second)
Примерно 3-5 млн новых в месяц, остальное - старые (возможно с изменениями).
Процент изменившихся старых - ещё примерно 10% в месяц.
> и вас заботит рост значения в auto_increment (непонятно, почему - это ни на что в общем не влияет)
Сейчас - не влияет, но через три с половиной года (для int) когда таблица забьётся - начнёт.
Перейти на big int, конечно, вариант - но я задал этот вопрос как раз чтобы понять плюсы и минусы и подходы.
По опыту - начиная с сотен миллионов записей случайный (в кортеже - два хеша мд5) первичный ключ даёт огромные замедления при вставке.
И решение - сделать ключ unique, а на primary поставить auto increment - как бы тупо и странно оно не звучало - работает, и вставка становится нормальной.
Я не знаю, как и почему это работает, но на практике проверено не раз.