Привет, работаю на Denwere уже давно, но только сейчас заметил одну особенность.
Если выключить Denwer и опять запустить, то все поля AUTO_INCREMENT будут считаться от последнего.
То есть если последний уникальный ID был 10 то следующий соответственно будет 11, но если например создать 11 12 и удалить их - следующий будет 13 индекс (если я не остановлю и запущу Denwer снова, если перезапущу - то следующий индекс будет не 13, а 11 так как 10 был последний), если же таблица пуста, то индексы будут считаться с 1.
Вопрос: За это отвечает какая та настройка MySQL для InnoDB ?
Denwer служит как тест - то что меняются индексы меня не особо тревожит. Но вот на выделенном VPS сервере мне нужно чтоб после перезагрузки индексы не затрагивались... (Если от строки с индексом 150 было удалено 300 строк и следующий авто индекс должен быть 451 то после перезагрузки VPS мне нужно чтоб этот 451 индекс был следующий, а не как на Denwere 151).
Подскажите за эта какая та настройка InnoDB отвечает? или же эта такая особенность MySQL и изменить ее нельзя?
Полная Версия: Denwer AUTO_INCREMENT InnoDB
это точно не особенность MySQL. какой-то скриптик у тебя запускается в денвере при старте, который сбрасывает автоинкремент на последний ид.
| Цитата (redreem @ 20.05.2016 - 18:55) |
| это точно не особенность MySQL. какой-то скриптик у тебя запускается в денвере при старте, который сбрасывает автоинкремент на последний ид. |
У меня абсолютно все скрипты написаны мной, в каждом я уверен.
Нашел ответ тут http://voituk.kiev.ua/2008/08/22/auto-incr...isam-vs-innodb/
В самом конце статьи написано
"Выход тут один - при использовании InnoDB в обязательном порядке все связи строить внешними ключами с каскадным удалением."
Не могу понять что конкретно нужно сделать... Может кто то подсказать что имел ввиду автор?
Это особенность InnoDB, данная подсистема при запуске инициализирует значения для auto increment, на основе максимальных значений id таблиц и держит их в памяти(ОЗУ). Соответственно при перезапуске/остановке процесса эти данные теряются. Настройки, которые могли бы повлиять на это - нет.
http://dev.mysql.com/doc/refman/5.7/en/inn...t-handling.html
_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
http://dev.mysql.com/doc/refman/5.7/en/inn...t-handling.html
_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
| Цитата (T1grOK @ 20.05.2016 - 21:00) |
| Это особенность InnoDB |
не знал, спасибо
| Цитата (T1grOK @ 20.05.2016 - 19:00) |
| Это особенность InnoDB, данная подсистема при запуске инициализирует значения для auto increment, на основе максимальных значений id таблиц и держит их в памяти(ОЗУ). Соответственно при перезапуске/остановке процесса эти данные теряются. Настройки, которые могли бы повлиять на это - нет. http://dev.mysql.com/doc/refman/5.7/en/inn...t-handling.html |
ясно, придется в другую таблицу записывать последний добавленный индекс (для некоторых таблиц это необходимо), а уже потом при добавлении создавать индекс исходя из этой таблицы
| Цитата (file_xz @ 20.05.2016 - 20:16) |
| ясно, придется в другую таблицу записывать последний добавленный индекс (для некоторых таблиц это необходимо), а уже потом при добавлении создавать индекс исходя из этой таблицы |
Invis1ble
сам рисовал?
за идею 5, за типографику - 2
сам рисовал?
за идею 5, за типографику - 2
| Цитата (file_xz @ 20.05.2016 - 16:16) |
| ясно, придется в другую таблицу записывать последний добавленный индекс (для некоторых таблиц это необходимо), а уже потом при добавлении создавать индекс исходя из этой таблицы |
Неверное решение, лучше побеспокоиться о удалении всей связанной информации для достижения консистентности данных.
Путей решения несколько:
- как выше вы упомянули это внешние ключи (что это и как работает можно узнать в гугл). Это наиболее предпочтительный подход.
- там где невозможно связать внешними ключами, можно использовать триггеры на уровне СУБД или на уровне приложения.
Также отмечу, что если на удаляемые данные есть ссылки в других хранилищах или СУБД(тот же redis), то нужно и там выполнить очистку иначе есть риск, получить новые строки "с чужими" данными.
И в дополнение, можно уже задействовать подобное вашему решению, чтобы автоинкремент "не слетал" https://www.slicewise.net/datenbanken/mysql...rung-vermeiden/
_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
| Цитата (redreem @ 20.05.2016 - 20:31) |
| сам рисовал? |
нет конечно, из меня художник как из говна пуля
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
Здесь расположена полная версия этой страницы.