I have a lot of tables and because of some reasons I need to adjust auto increment value for this tables on application startup.
I try to do this:
mysql> select max(id) from item;
+----------+
| max(id) |
+----------+
| 97972232 |
+----------+
1 row in set (0.05 sec)
mysql> alter table item auto_increment=1097972232;
In another session:
afrolov@A1-DB1:~$ mysql -u root -e "show processlist" | grep auto_increment
472196 root localhost test Query 39 copy to tmp table alter table item auto_increment=1097972232
MySQL is starting to rebuild table! Why MySQL need to do it? How can I avoid rebuilding huge tables while adjusting auto_increment value?
MySQL 5.0, InnoDB.
Table definition:
CREATE TABLE `item` (
`id` bigint(20) NOT NULL auto_increment,
`item_res_id` int(11) NOT NULL default '0',
`stack_count` int(11) NOT NULL default '0',
`position` int(11) NOT NULL default '0',
`place` varchar(15) NOT NULL default '',
`counter` int(11) NOT NULL default '-1',
`is_bound` tinyint(4) NOT NULL default '0',
`remove_time` bigint(20) NOT NULL default '-1',
`rune_res_id` int(11) default NULL,
`rune_id` bigint(20) default NULL,
`avatar_id` bigint(20) NOT NULL,
`rune_slot_res_id` int(11) default NULL,
`is_cursed` tinyint(4) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `avatar_id` (`avatar_id`,`place`,`position`),
UNIQUE KEY `rune_id` (`rune_id`),
KEY `idx_item_res_id` (`item_res_id`)
) ENGINE=InnoDB AUTO_INCREMENT=97972233 DEFAULT CHARSET=utf8;
About why I have to do this. Long story short i want to workaround mysql innodb issue about reseting auto_increment value on server restart. Sometimes we copy rows from our tables to another tables and we must keep rows id unchanged. When we add one row (with id=1 for example) to table1, copy row to table2 , delete row from table1 and restart MySQL, then when we create a new one row in table1 this row will get id=1 too. So if we will have to copy row to table2 we get unique constraint violation. We already have a lot of code and it will be hard to rewrite it all. Adjusting autoincrement value seems the easiest way to fix this problem.
Added:
MySQL 5.5 - all the same :(
simply add a temporary record that has desired auto_increment_id-1
to each table,
and remove the record after that, quick and easy, but probably too dirty
example:
insert into item set id=1097972232-1;
after the execution, the next auto_increment will be 1097972232, which is what you desired
this can avoid slowness
This is a documented "feature" of MySQL:
If you use any option to ALTER TABLE other than RENAME, MySQL always creates a temporary table, even if the data wouldn't strictly need to be copied (such as when you change the name of a column). For MyISAM tables, you can speed up the index re-creation operation (which is the slowest part of the alteration process) by setting the myisam_sort_buffer_size system variable to a high value.
http://dev.mysql.com/doc/refman/5.0/en/alter-table.html
MySQL 5.1 and 5.5 support a few more alter table operations w/o a temporary table, but changing the auto_increment is not documented to be one of those.
Why do you need to change the auto_increment value, anyway? This isn't something you should be doing routinely.
There is no simple way to get around the AUTO_INCREMENT
attribute default behavior in MySQL, and even if you find a way, I wouldn't recommend you to do so, since it is the best way to run into problems in the short-term. AUTO_INCREMENT
values are not meant to be adjusted or reseted in a production environment.
One possible solution to your problem could be to denormalize your model a little. The idea is to move the AUTO_INCREMENT
field to a side table where you don't have to copy or delete rows. All you have to do then is to get a new id value from this side table when you create a new item, and keep the existing id value when you copy rows from one table to another.
To achieve this we will use a trigger that will create a new id for us and assign it to our item record. The id field of the item table has to be nullable for this to work, so we have to replace the primary key by a unique index.
This model change would be completely transparent for your application, so you would have no change to make in your application code.
Here are some example scripts. Let's say we have two item tables in our database, with some common rows, and some rows that need to be moved from first table to second table:
CREATE TABLE `item1` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `item_res_id` int(11) NOT NULL DEFAULT '0', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE `item2` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `item_res_id` int(11) NOT NULL DEFAULT '0', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; INSERT INTO item1 (item_res_id) VALUES (1); INSERT INTO item1 (item_res_id) VALUES (2); INSERT INTO item2 (item_res_id) VALUES (1);
If we try to move some data from one table to another and then restart your server, we will encounter the issue of AUTO_INCREMENT
value reset. So we will slightly modify our model as follows:
We will proceed in several steps to migrate our data model. The DDL statements in the following migration scripts have been generated using neXtep Designer IDE.
- First we create a new item_keys table that will hold the
AUTO_INCREMENT
field:
-- Creating table 'item_keys' CREATE TABLE item_keys ( id BIGINT(20) UNSIGNED NOT NULL ,key_ctime TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ) Engine=InnoDB default charset=utf8; -- Creating Primary Key constraint 'PRIMARY' on table 'item_keys' ALTER TABLE item_keys ADD CONSTRAINT PRIMARY KEY (id);
- But before activating the
AUTO_INCREMENT
attribute, we must insert existing ids into our new table:
-- Initializing item_keys with existing ids INSERT INTO item_keys (id) SELECT i1.id FROM item1 i1 LEFT JOIN item_keys ik ON ik.id = i1.id WHERE ik.id IS NULL ; INSERT INTO item_keys (id) SELECT i2.id FROM item2 i2 LEFT JOIN item_keys ik ON ik.id = i2.id WHERE ik.id IS NULL ;
- We can now activate the
AUTO_INCREMENT
attribute, and initialize its value for future inserts:
-- Activating auto_increment constraint... ALTER TABLE item_keys MODIFY id BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT; -- Initializing auto_increment value SELECT @inc_value := MAX(id) FROM item_keys; SET @alter_query = CONCAT('ALTER TABLE item_keys AUTO_INCREMENT=',@inc_value); PREPARE alter_query FROM @alter_query; EXECUTE alter_query; DEALLOCATE PREPARE alter_query;
- Then we can alter the
item1
anditem2
tables to replace the primary key by a unique index, and reference the primary key of the item_keys table:
-- De-activating auto_increment constraint... ALTER TABLE item1 MODIFY id BIGINT(20) UNSIGNED NOT NULL; -- Dropping constraint 'PRIMARY'... ALTER TABLE item1 DROP PRIMARY KEY; ALTER TABLE item1 MODIFY id BIGINT(20) UNSIGNED NULL; -- Creating index 'item1_uk'... CREATE UNIQUE INDEX item1_uk ON item1 (id); -- Creating Foreign Key constraint 'item1_keys_fk' on table 'item1' ALTER TABLE item1 ADD CONSTRAINT item1_keys_fk FOREIGN KEY item1_keys_fk (id) REFERENCES item_keys (id) ;
-- De-activating auto_increment constraint... ALTER TABLE item2 MODIFY id BIGINT(20) UNSIGNED NOT NULL; -- Dropping constraint 'PRIMARY'... ALTER TABLE item2 DROP PRIMARY KEY; ALTER TABLE item2 MODIFY id BIGINT(20) UNSIGNED NULL; -- Creating index 'item2_uk'... CREATE UNIQUE INDEX item2_uk ON item2 (id); -- Creating Foreign Key constraint 'item2_keys_fk' on table 'item2' ALTER TABLE item2 ADD CONSTRAINT item2_keys_fk FOREIGN KEY item2_keys_fk (id) REFERENCES item_keys (id) ;
- Finally, we just have to create the triggers that will manage the ids creation for us:
-- Creating trigger 'tr_item1_bi' on table 'item1'... DELIMITER |; CREATE TRIGGER tr_item1_bi BEFORE INSERT ON item1 FOR EACH ROW BEGIN IF (NEW.id IS NULL) THEN -- If no item id has been specified in the INSERT statement, it -- means we want to create a new item. We insert a new record -- into the item_keys table to get an item id. INSERT INTO item_keys ( key_ctime ) VALUES (NOW()); SET NEW.id = LAST_INSERT_ID(); END IF; END; |;
-- Creating trigger 'tr_item2_bi' on table 'item2'... DELIMITER |; CREATE TRIGGER tr_item2_bi BEFORE INSERT ON item2 FOR EACH ROW BEGIN IF (NEW.id IS NULL) THEN -- If no item id has been specified in the INSERT statement, it -- means we want to create a new item. We insert a new record -- into the item_keys table to get an item id. INSERT INTO item_keys ( key_ctime ) VALUES (NOW()); SET NEW.id = LAST_INSERT_ID(); END IF; END; |;
Now we can move data from one table to another, keeping the ids unchanged, and if we restart the server, the AUTO_INCREMENT
value in the item_keys
will stay the same.
-------------- INSERT INTO item2 SELECT i1.* FROM item1 i1 LEFT JOIN item2 i2 ON i2.id = i1.id WHERE i2.id IS NULL -------------- Query OK, 1 row affected (0.04 sec) Records: 1 Duplicates: 0 Warnings: 0 -------------- DELETE FROM item1 -------------- Query OK, 2 rows affected (0.00 sec) -------------- INSERT INTO item1 (item_res_id) VALUES (3) -------------- Query OK, 1 row affected (0.00 sec) -------------- SELECT * FROM item1 -------------- +------+-------------+ | id | item_res_id | +------+-------------+ | 3 | 3 | +------+-------------+ 1 row in set (0.00 sec) -------------- SELECT * FROM item2 -------------- +------+-------------+ | id | item_res_id | +------+-------------+ | 1 | 1 | | 2 | 2 | +------+-------------+ 2 rows in set (0.00 sec) -------------- SELECT * FROM item_keys -------------- +----+---------------------+ | id | key_ctime | +----+---------------------+ | 1 | 2010-11-14 10:31:21 | | 2 | 2010-11-14 10:31:21 | | 3 | 2010-11-14 10:31:46 | +----+---------------------+ 3 rows in set (0.00 sec)
If you need to maintain unique IDs between two or more servers, don't use this alter table method of resetting the auto_increment each time. It'd be easier to change the increment's increment so that each server will generate unique IDs without intervention. For two servers, you set one to start at 0 and one to start at 1, with an increment of 2 - afterward one will generate even IDs, the other will generate odds. With 3 or more servers, you just set the initial values to 0/1/2 with increments of 3, for four it's 0/1/2/3 with inc of 4, etc...
Details on the server-side settings here:
This way you only have to reset the auto_increment once per table per server, and afterward they'll take care of the uniqueness problem automatically.
来源:https://stackoverflow.com/questions/4124838/slow-auto-increment-reset