История изменений
Исправление surefire, (текущая версия) :
Таблица не очень большая всего чуть больше 100 000 строк. Давно было, точно не помню, но вроде бы я успел до часа икс произвести ALTER TABLE. Уникальных данных которые больно терять там почти нет, так актуальное за последние пару часов. Меня насторожило, что autoincrement дико несоразмерен количеству строк и перепрыгнул миллиардный рубеж. Начал разбираться и выяснил, что всему виной INSERT ON DUPLICATE KEY UPDATE. Поспрашивал гугла, и он вывел на статьи с похожими проблемами. Кстати INSERT IGNORE работает подобным образом. То есть всегда autoincrement увеличивается и для вставки выделяется новый id, а уже потом либо да, либо нет. Уже несколько лет работает и обновляется круглые сутки и id всего около 150 000. Если б не избавился от INSERT ON DUPLICATE KEY сколько бы сейчас было миллиардов. Ну и надо не забывать, что кроме СУБД на огромных числах может споткнуться и софт который обращается к базе.
Исходная версия surefire, :
Таблица не очень большая всего чуть больше 100 000 строк. Давно было, точно не помню, но вроде бы я успел до часа икс произвести ALTER TABLE. Уникальных данных которые больно терять там почти нет, так актуальное за последние пару часов. Меня насторожило, что autoincrement дико несоразмерен количеству строк и перепрыгнул миллиардный рубеж. Начал разбираться и выяснил, что всему виной INSERT ON DUPLICATE KEY UPDATE. Поспрашивал гугла, и он вывел на статьи с похожими проблемами. Кстати INSERT IGNORE работает подобным образом. То есть всегда autoincremnt увеличивается и для вставки выделяется новый id, а уже потом либо да, либо нет. Уже несколько лет работает и обновляется круглые сутки и id всего около 150 000. Если б не избавился от INSERT ON DUPLICATE KEY сколько бы сейчас было миллиардов. Ну и надо не забывать, что кроме СУБД на огромных числах может споткнуться и софт который обращается к базе.