Как исправить предупреждение: найдена строка, в которой столбец auto_increment имеет значение 0 в mysql?

Я получаю это предупреждение, когда запускаю команду оптимизации базы данных mysql:

warning  : Found row where the auto_increment column has the value 0
status   : OK

Это предупреждение приходит к таблице пользователей, и я не уверен, что это не проблема для базы данных drupal. В Mysql есть это объяснение предупреждения:

Это не ошибка сама по себе, но может вызвать проблемы, если вы решите сбросить таблицу и восстановить ее или выполнить команду ALTER TABLE для таблицы. В этом случае столбец AUTO_INCREMENT изменяет значение в соответствии с правилами столбцов AUTO_INCREMENT, что может вызвать такие проблемы, как ошибка дублирования ключа.

Проблема, которая может иметь отношение к этому предупреждению, заключается в том, что всякий раз, когда я пытаюсь заблокировать пользователя, я получаю тайм-аут сервера, и запрос не вступает в силу. Я не знаю, какой запрос выполнить, чтобы определить строки, в которых это происходит.


person qliq    schedule 09.05.2011    source источник
comment
Очевидно, вы пытались выбрать строку с id = 0, верно?   -  person ariel    schedule 09.05.2011
comment
Нет, на самом деле просто запустите эту общую команду: 'mysqlcheck -uroot -pxxxxx --auto-repair --optimize --databases the_db'   -  person qliq    schedule 09.05.2011


Ответы (3)


Вы ничего не можете с этим поделать в Drupal 6. UID 0 и 1 имеют особое значение в Drupal и должны существовать именно так, хотя MySQL это не нравится (по уважительным причинам). По этим веским причинам это было исправлено/изменено в Drupal 7. Немного предыстории...

В Drupal 5 и более ранних версиях уровень базы данных не использовал AUTO INCREMENET из-за совместимости с другими базами данных. Все такие идентификаторы полагались на db_next_id(), который нужно было вызывать вручную перед вставкой новой строки.

В Drupal 6 был добавлен Schema API (позволяет определять схему в массивах PHP, после чего Drupal будет строить специфичные для базы данных запросы создания таблиц и т. д.). db_next_id() был удален, а для нескольких таблиц (в основном пользователей и действий) были добавлены некоторые хакерские обходные пути. Однако это приводит к проблемам (например, невозможность легко экспортировать и импортировать таблицу, как сообщает MySQL в описании предупреждения).

В Drupal 7 снова было добавлено db_next_id(), явно для таблиц, в которых AUTO_INCREMENT (называемый 'serial' в Drupal Schema API) не работает должным образом. проект User Relationships, который я поддерживаю для Drupal 7, тоже делал что-то странное с таблицей auto_increment (re -использование идентификаторов для соединения однонаправленных отношений), которые я недавно заменил на db_next_id(). Итак, если вы поддерживаете пользовательский или вспомогательный модуль, который позволяет обойти AUTO INCREMENT, вместо этого используйте db_next_id() в Drupal 7!

person Berdir    schedule 09.05.2011
comment
Спасибо Бердир за подробное объяснение. У вас также есть идеи, почему я не могу блокировать пользователей? - person qliq; 09.05.2011

Drupal использует uid=0 для анонимных пользователей, а реальные пользователи получают автоматически увеличивающиеся UID. Так что это ожидаемое поведение, и я бы не ожидал, что оно будет связано с вашей ошибкой тайм-аута. Для этого вы можете увеличить лимит памяти PHP.

person Scott Reynen    schedule 09.05.2011
comment
Кстати, я увеличил memory_limit до 512M, но проблема с тайм-аутом осталась. - person qliq; 09.05.2011

Это похоже на ошибку дизайна в Drupal, свяжитесь с авторами :)

Столбцы с автоматическим приращением никогда не должны иметь значение 0, так как вставить такое значение сложно, поэтому дамп/восстановление может не работать.

Они не должны использовать значение автоинкремента в таблице, для которой требуется строка с явным значением 0 для столбца автоинкремента. В общем, вы вообще не должны полагаться на «волшебные идентификаторы» в столбцах auto-inc.

person MarkR    schedule 09.05.2011
comment
Правильно, и это было исправлено в Drupal 7, см. мой ответ для более подробной информации. - person Berdir; 09.05.2011