MySQL Автоматически увеличивает значения После УДАЛЕНИЯ без указания WHERE

Question

Я заметил это после пробежки,

DELETE FROM tablename

Мои значения ID (автоматическое увеличение) стали странными

7, 8, 9, 0, 1, 12, 3, 4, 15 

В таком порядке, когда я делаю,

SELECT * FROM tablename

Я знаю, что в руководстве по сертификации говорится, что идентификаторы могут быть сброшены, а могут и не быть сброшены, когда для очистки таблицы используется функция DELETE без WHERE, но что заставило последовательность идентификаторов быть такой странной?Я совершенно уверен, что именно в таком порядке были вставлены строки.Первоначально перед удалением у меня было 6 строк в таблице, поэтому 7, 8, 9 кажутся понятными.

Answer 1

в связи с вашими снимками экрана:http://img19.imageshack.us/img19/7336/82051321.png и http://img27.imageshack.us/img27/2935/24285862.png

проблема в вашем "коде приложения".вы используете файл LOAD DATA INFILE с файлом, который имеет окончания строк в стиле Windows ( \ n), а по умолчанию в mysql, если не указано иное, используется стиль unix ( ).

чтобы понять, что я имею в виду, попробуйте следующее:

mysql> load data infile 'data.txt' into table testDel (val);
Query OK, 6 rows affected (0.01 sec)
Records: 6  Deleted: 0  Skipped: 0  Warnings: 0

mysql> select * from testDel;
+----+----------------+
| id | val            |
+----+----------------+
 | 7 | hello world 1
 | 8 | hello world 2
 | 9 | hello world 3
 | 0 | hello world 4
 | 1 | hello world 5
| 12 | hello world 6  |
+----+----------------+
6 rows in set (0.00 sec)

mysql> select id, hex(val) from testDel;
+----+------------------------------+
| id | hex(val)                     |
+----+------------------------------+
|  7 | 68656C6C6F20776F726C6420310D |
|  8 | 68656C6C6F20776F726C6420320D |
|  9 | 68656C6C6F20776F726C6420330D |
| 10 | 68656C6C6F20776F726C6420340D |
| 11 | 68656C6C6F20776F726C6420350D |
| 12 | 68656C6C6F20776F726C642036   |
+----+------------------------------+
6 rows in set (0.01 sec)

что происходит, так это то, что \ r мешает отображению ваших значений.вы заметили, что "стены" ваших столов не выстраиваются в линию?это должно быть намеком на то, что что-то не так с отображением, о чем свидетельствует запрос с шестнадцатеричным значением (val), где "стены" действительно выстраиваются в линию.

чтобы исправить импорт, вы должны указать окончания строк в файле:

mysql> load data infile 'data.txt' into table testDel lines terminated by '\r\n' (val);
Query OK, 6 rows affected (0.00 sec)
Records: 6  Deleted: 0  Skipped: 0  Warnings: 0

mysql> select * from testDel;
+----+---------------+
| id | val           |
+----+---------------+
| 13 | hello world 1 |
| 14 | hello world 2 |
| 15 | hello world 3 |
| 16 | hello world 4 |
| 17 | hello world 5 |
| 18 | hello world 6 |
+----+---------------+
6 rows in set (0.00 sec)

Answer 2

Нет абсолютно никакого подобия или гарантии порядка в базе данных без order by оговорка.Это связано с тем, как хранятся записи - они не хранятся в какой-либо последовательности.База данных часто оптимизирует способ хранения данных на основе кластеризованных индексов, но каждая база данных хранит данные немного по-разному.

Вы никогда, никогда, никогда не должны думать, что у вас будет повторяемый заказ если не вы используете order by оговорка.

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

Answer 3

Вместо УДАЛЕНИЯ ИЗ вы должны попробовать

TRUNCATE tablename

Я полагаю, что это также сбросит последовательность для ID.

Answer 4

здесь что-то происходит, помимо простого УДАЛЕНИЯ, затем 10 простых ВСТАВОК, затем простой ВЫБОР.у вас есть 0 в вашем списке идентификаторов, что означает, что что-то где-то указывает значения для вашего столбца auto_increment.

я бы проверил код вашего приложения.

если это не так, то вам нужно придумать определенный набор шагов (включая СОЗДАНИЕ ТАБЛИЦЫ), который показывает, как можно воспроизвести эту проблему.