I see a weird behavior where my auto-increment column number is only increasing in a step of 2 instead of 1. So I end up with row ids as 1, 3, 5, 7. I use MySQL 5.6 + InnoDB as the engine. Any idea why this weirdness?
mysql> select version();
+-----------------+
| version() |
+-----------------+
| 5.6.20-68.0-log |
+-----------------+
1 row in set (0.00 sec)
mysql> show create table temp_table;
| superset_version | CREATE TABLE `temp_table` (
`_id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'comm1',
`name` varchar(100) NOT NULL COMMENT 'comm2',
`start_time` bigint(20) NOT NULL COMMENT 'comm3',
`updated_at` bigint(20) NOT NULL COMMENT 'comm4',
`status` varchar(50) NOT NULL COMMENT 'comm5',
PRIMARY KEY (`_id`)
) ENGINE=InnoDB AUTO_INCREMENT=27 DEFAULT CHARSET=utf8 |
Notice that insert incremented the _id column by a difference of 2.
mysql> insert into superset_version(name, start_time, updated_at, status) value("TEMP ROW", -1, -1, "erro");
Query OK, 1 row affected, 1 warning (0.00 sec)
mysql> select * from superset_version order by _id desc limit 3;
+-----+----------+------------+------------+--------+
| _id | name | start_time | updated_at | status |
+-----+----------+------------+------------+--------+
| 33 | TEMP ROW | -1 | -1 | erro |
| 31 | TEMP ROW | -1 | -1 | erro |
| 29 | TEMP ROW | -1 | -1 | erro |
+-----+----------+------------+------------+--------+
3 rows in set (0.00 sec)
auto_increment_increment setting is most likely set to 2, therefore mysql increases auto increment numbers by 2. Use show varibles like ... command to check the setting.
for double check you could try:
SELECT AUTO_INCREMENT
From `information_schema`.`TABLES`
WHERE TABLE_NAME = '<<YOUR TABLE NAME HERE>>' AND
TABLE_SCHEMA = '<< YOUR DATABASE NAME HERE >>'
if the step is really equals 2, it's possible to replace it.
or one another way:
Check values in:
mysql.cnf / ini:
auto-increment-increment
auto-increment-offset
Related
So I have a table where a column that was given an auto_increment value accidentally got started form 300 instead of 1,2,3,4......i'm a beginner and i do not know how to change it back to 1,2,3,4......screenshot of table
how to change the 307, 308 to 1,2,3,4...?
I tried to update the table but that did not work.
Step-1) First take backup of your table data.
Step-2) Truncate the table by using the below SQL query.
TRUNCATE TABLE [Your_Table_Name];
Step-3) then again insert the into your table using backup data.
Alter table to drop the auto_increment, update, alter table to add the auto_increment
drop table if exists t;
create table t
( id int auto_increment primary key, val int);
insert into t values
(307,1),(308,1),(309,1),(310,1),(311,1);
alter table t
modify column id int;
#drop primary key;
show create table t;
update t
set id = id - 306;
alter table t
modify column id int auto_increment;
show create table t;
https://dbfiddle.uk/eBQh6cj8
With MySQL 8.0 you can use a window function to calculate the row numbers and then update the table:
mysql> select * from t;
+-----+------+
| id | val |
+-----+------+
| 307 | 1 |
| 308 | 1 |
| 309 | 1 |
| 310 | 1 |
| 311 | 1 |
+-----+------+
mysql> with cte as ( select id, row_number() over () as rownum from t )
-> update t join cte using (id) set id = rownum;
Query OK, 5 rows affected (0.00 sec)
Rows matched: 5 Changed: 5 Warnings: 0
mysql> select * from t;
+----+------+
| id | val |
+----+------+
| 1 | 1 |
| 2 | 1 |
| 3 | 1 |
| 4 | 1 |
| 5 | 1 |
+----+------+
Then make sure the next id won't be a high value:
mysql> alter table t auto_increment=1;
You can try to set the auto_increment to 1, MySQL will automatically advances that to the highest id value in the table, plus 1.
Be aware that this doesn't guarantee subsequent rows will use consecutive values. You can get non-consecutive values if:
You insert greater values explicitly, overriding the auto-increment.
You roll back transactions. Id values generated by auto-increment are not recycled if you roll back.
You delete rows.
Occasionally InnoDB will skip a number anyway. It does not guarantee consecutive values — it only guarantees unique values. You should not rely on the auto-increment to be the same as a row number.
Here is a one approach to your problem.
Please take note of the following points before proceeding:
Take backup of your table in-case things do not go as expected.
Below test case has been performed on MySQL 5.7 and MyISAM Engine.
Step1: Generating dummy test table as per your test case.
mysql> CREATE TABLE t (
-> `Id` int(11) NOT NULL AUTO_INCREMENT,
-> `product_id` int(11) DEFAULT 0,
-> PRIMARY KEY (`Id`)
-> ) ENGINE=MyISAM;
Query OK, 0 rows affected (0.03 sec)
-- Inserting dummy data
mysql> INSERT INTO t VALUES (300,1);
Query OK, 1 row affected (0.00 sec)
mysql> INSERT INTO t VALUES (302,1);
Query OK, 1 row affected (0.00 sec)
mysql> INSERT INTO t VALUES (305,1);
Query OK, 1 row affected (0.00 sec)
-- Checking auto_increment value
mysql> show create table t;
+-------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table |
+-------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| t | CREATE TABLE `t` (
`Id` int(11) NOT NULL AUTO_INCREMENT,
`product_id` int(11) DEFAULT '0',
PRIMARY KEY (`Id`)
) ENGINE=MyISAM AUTO_INCREMENT=306 DEFAULT CHARSET=latin1 |
+-------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
mysql> INSERT INTO t (product_id) VALUES (2);
Query OK, 1 row affected (0.01 sec)
-- Below is the resultant table for which we need Id starting from 1,2,3 and so on...
mysql> SELECT * FROM t;
+-----+------------+
| Id | product_id |
+-----+------------+
| 300 | 1 |
| 302 | 1 |
| 305 | 1 |
| 306 | 2 |
+-----+------------+
4 rows in set (0.00 sec)
Step2: Remove AUTO_INCREMENT for the column and set the Ids manually.
-- Remove AUTO_INCREMENT
mysql> ALTER TABLE t MODIFY COLUMN Id int(11) NOT NULL;
Query OK, 4 rows affected (0.00 sec)
Records: 4 Duplicates: 0 Warnings: 0
-- Set the Id manually starting from 1
mysql> SET #i = 0;UPDATE t SET id = #i :=#i +1;
Query OK, 0 rows affected (0.00 sec)
Query OK, 5 rows affected (0.00 sec)
Rows matched: 5 Changed: 5 Warnings: 0
-- Below is the updated table with Id starting from 1,2,3 and so on...
mysql> SELECT * FROM t;
+----+------------+
| Id | product_id |
+----+------------+
| 1 | 1 |
| 2 | 1 |
| 3 | 1 |
| 4 | 2 |
| 5 | 2 |
+----+------------+
5 rows in set (0.00 sec)
Step3: Enable AUTO_INCREMENT again for future record insertions.
-- Enable AUTO_INCREMENT again for future record insertions.
mysql> ALTER TABLE t MODIFY COLUMN Id int(11) NOT NULL AUTO_INCREMENT;
Query OK, 5 rows affected (0.01 sec)
Records: 5 Duplicates: 0 Warnings: 0
-- Set the AUTO_INCREMENT value to continue from highest value of id in the table.
mysql> SELECT MAX(id+1) FROM t;
+-----------+
| MAX(id+1) |
+-----------+
| 6 |
+-----------+
1 row in set (0.00 sec)
mysql> ALTER TABLE t AUTO_INCREMENT=6;
Query OK, 5 rows affected (0.00 sec)
Records: 5 Duplicates: 0 Warnings: 0
-- Table is successfully modified and will have future records inserted with no gaps in Id's
mysql> INSERT INTO t (product_id) VALUES (5);
Query OK, 1 row affected (0.00 sec)
mysql> SELECT * FROM t;
+----+------------+
| Id | product_id |
+----+------------+
| 1 | 1 |
| 2 | 1 |
| 3 | 1 |
| 4 | 2 |
| 5 | 2 |
| 6 | 5 |
+----+------------+
6 rows in set (0.00 sec)
The DBCC CHECKIDENT management command is used to reset identity counter
DBCC CHECKIDENT (table_name [, { NORESEED | { RESEED [, new_reseed_value]}}])
[ WITH NO_INFOMSGS ]
EXample:
DBCC CHECKIDENT ('TestTable', RESEED, 0)
GO
many times we need to just reseed to next Id available
declare #max int
select #max=max([Id]) from [TestTable]
if #max IS NULL --check when max is returned as null
SET #max = 0
DBCC CHECKIDENT ('[TestTable]', RESEED, #max)
This will check the table and reset to the next ID.
You can get help from the link below:
Reset identity seed after deleting records in SQL Server
My mother says: the mountain that can be seen is not far away, don't stop trying
This is MariaDB + TokuDB 7.1 community downloaded from Tokutek. Please accept my ignorance if this is normal behavior but I have a question about sorting results. I'm experiencing huge time difference in sorting between the two sort directions - ascending and descending:
SELECT sql_no_cache id, createts, deleted
FROM sort_test
WHERE createts > '2000098'
ORDER BY createts asc
+---------+----------+---------+
| id | createts | deleted |
+---------+----------+---------+
| 1999999 | 2000099 | NULL |
| 2000000 | 2000100 | NULL |
+---------+----------+---------+
2 rows in set (0.00 sec)
SELECT sql_no_cache id, createts, deleted
FROM sort_test
WHERE createts > '2000098'
ORDER BY createts desc
+---------+----------+---------+
| id | createts | deleted |
+---------+----------+---------+
| 2000000 | 2000100 | NULL |
| 1999999 | 2000099 | NULL |
+---------+----------+---------+
2 rows in set (0.55 sec)
Below I present my simplified test case. Here is the table:
CREATE TABLE `sort_test` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`createts` int(11) DEFAULT NULL,
`deleted` int(11) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `idx_createts` (`createts`)
) ENGINE=TokuDB
Here I populate the table with 2 million rows using this procedure:
delimiter ;;
drop procedure if exists sort_test_populate;;
create procedure sort_test_populate()
begin
DECLARE int_val INT DEFAULT 1;
myloop : LOOP
if (int_val > 2000000) THEN
LEAVE myloop;
end if;
insert into sort_test (id, createts) values (int_val, int_val+100);
set int_val = int_val +1;
end loop;
end;;
call sort_test_populate();;
Query OK, 1 row affected (28 min 2.80 sec)
Here are my test queries again:
SELECT sql_no_cache id, createts, deleted
FROM sort_test
WHERE createts > '2000098'
ORDER BY createts asc
2 rows in set (0.00 sec)
SELECT sql_no_cache id, createts, deleted
FROM sort_test
WHERE createts > '2000098'
ORDER BY createts desc
2 rows in set (0.55 sec)
And here is the "explain extended" result, it's identical for both queries:
+------+-------------+-----------+-------+---------------+--------------+---------+------+------+----------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+------+-------------+-----------+-------+---------------+--------------+---------+------+------+----------+-------------+
| 1 | SIMPLE | sort_test | range | idx_createts | idx_createts | 5 | NULL | 2 | 100.00 | Using where |
+------+-------------+-----------+-------+---------------+--------------+---------+------+------+----------+-------------+
Please note that this is not my exact data I'm working with, that would be too much to include here. I just wanted to create some test data to demonstrate the problem. My question is - why it's behaving like this and how to make the descending order query faster?
This is a known bug with Index Condition Pushdown (ICP). The workaround is to disable ICP by setting the optimizer_switch either globally or within the session executing this query.
mysql> SET optimizer_switch='index_condition_pushdown=off';
(full disclosure, I'm an employee at Tokutek, makers of TokuDB)
I have the following table structure (using SHOW CREATE command just now):
CREATE TABLE `ipstats` (
`id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
`ip` VARCHAR(15) NOT NULL,
`online` ENUM('n','y') NOT NULL DEFAULT 'y',
`last_used` DATETIME NOT NULL DEFAULT '1981-09-30 00:00:00',
PRIMARY KEY (`id`),
UNIQUE INDEX `ip` (`ip`)
)
COLLATE='utf8_general_ci'
ENGINE=MyISAM
AUTO_INCREMENT=253691;
Now, I simply fetch a few recent values (I've changed the IPs for demonstration):
mysql> SELECT * FROM ipstats ORDER BY id DESC LIMIT 10;
+--------+----------------+--------+---------------------+
| id | ip | online | last_used |
+--------+----------------+--------+---------------------+
| 253690 | 10.204.102.38 | n | 2013-10-19 14:14:33 |
| 253689 | 10.188.124.196 | n | 2013-10-19 10:46:25 |
| 253688 | 10.166.124.194 | n | 2013-10-19 16:49:40 |
| 253687 | 10.250.137.166 | n | 2013-10-19 13:51:56 |
| 253686 | 10.221.102.39 | n | 2013-10-19 14:13:03 |
| 253685 | 10.129.102.57 | n | 2013-10-19 18:45:20 |
| 253684 | 10.214.102.39 | n | 2013-10-19 03:43:55 |
| 253683 | 10.31.142.41 | n | 2013-10-19 17:27:08 |
| 253682 | 10.41.142.154 | n | 2013-10-19 00:52:11 |
| 253681 | 10.41.124.84 | n | 2013-10-19 10:37:12 |
+--------+----------------+--------+---------------------+
After this, I'll try to execute a simple INSERT statement:
INSERT INTO `ipstats` (`ip`, `last_used`)
VALUES ( '10.3.100.244', NOW() )
ON DUPLICATE KEY UPDATE
`online` = 'y',
`last_used` = NOW(),
`id` = LAST_INSERT_ID(`id`)
where the value 10.3.100.244 does not already exist in the table. It results in:
ERROR 1062 (23000): Duplicate entry '253691' for key 'PRIMARY'
Selecting the LAST_INSERT_ID gives:
mysql> SELECT LAST_INSERT_ID();
+------------------+
| LAST_INSERT_ID() |
+------------------+
| 0 |
+------------------+
If that wasn't already weird behaviour; I'll try to insert an already existing IP entry:
mysql> INSERT INTO `ipstats` (`ip`, `last_used`) VALUES ( '10.204.102.38', NOW() ) ON DUPLICATE KEY UPDATE `online` = 'y', `last_used` = NOW(), `id` = LAST_INSERT_ID(`id`);
ERROR 1062 (23000): Duplicate entry '253691' for key 'PRIMARY'
I'm now officially stumped at this behaviour from MySQL. All other queries are working fine in all other processes that are running. The error is occurring only when I try to INSERT to the ipstats table. I even tried the following:
mysql> UPDATE ipstats
SET `online` = 'n',
`last_used` = NOW(),
`id` = LAST_INSERT_ID(`id`)
WHERE ip = '10.204.102.38';
Affected rows: 1 Found rows: 0 Warnings: 0 Duration for 1 query: 0.000 sec.
mysql> SELECT LAST_INSERT_ID();
+------------------+
| LAST_INSERT_ID() |
+------------------+
| 253690 |
+------------------+
Affected rows: 0 Found rows: 1 Warnings: 0 Duration for 1 query: 0.000 sec.
mysql> INSERT INTO `ipstats` (`ip`, `last_used`)
VALUES ( '10.204.102.38', NOW() )
ON DUPLICATE KEY UPDATE
`online` = 'y',
`last_used` = NOW(),
`id` = LAST_INSERT_ID(`id`);
Error 1062 (23000): Duplicate entry '253691' for key 'PRIMARY'
What could be the problem? How can I resolve this? The error has been occurring since today afternoon and I never faced such a problem before.
P.S.: The error occurs with all user-accounts in my MySQL installation. There are 4 users (including root) who can access the database. None of them is able to perform the INSERT query.
A force insertion of a new row (with id different from 253691) seems to have solved this problem for now. I am still not sure as to why the error occurred.
The command I used was:
INSERT INTO `ipstats` (id, ip, online, last_used)
VALUES ( 253699, '10.204.102.38', 'n', NOW() );
and the system was working normally again (for all 4 users, on every connection). I'll leave the question as still unanswered since I still don't know what caused the problem. My best guess would be that it is a possible MySQL bug.
So I have the following table:
mysql> show create table user_api_skills \G
*************************** 1. row ***************************
Table: user_api_skills
Create Table: CREATE TABLE `user_api_skills` (
`characterID` int(11) NOT NULL,
`typeID` int(11) NOT NULL,
`level` enum('0','1','2','3','4','5') NOT NULL DEFAULT '0',
`skillpoints` int(11) NOT NULL,
`currentTime` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`characterID`,`typeID`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)
mysql>
And in that table a row which I am trying to insert/update:
mysql> SELECT * FROM `user_api_skills` WHERE `characterID` =93192782 AND `typeID` =3359;
+-------------+--------+-------+-------------+---------------------+
| characterID | typeID | level | skillpoints | currentTime |
+-------------+--------+-------+-------------+---------------------+
| 93192782 | 3359 | 3 | 135765 | 2013-09-30 16:58:35 |
+-------------+--------+-------+-------------+---------------------+
1 row in set (0.00 sec)
I believe my query is correctly formed and when executed it doesn't throw any errors or warnings:
mysql> INSERT INTO user_api_skills (characterID,typeID,level,skillpoints)
VALUES (93192782,3359,4,135765) ON DUPLICATE KEY UPDATE level=4,
skillpoints=135765,currentTime=NOW();
Query OK, 2 rows affected (0.22 sec)
I get 2 rows updated (as I would expect from an insert on dup update)
mysql> SELECT * FROM `user_api_skills` WHERE `characterID` =93192782 AND `typeID` =3359;
+-------------+--------+-------+-------------+---------------------+
| characterID | typeID | level | skillpoints | currentTime |
+-------------+--------+-------+-------------+---------------------+
| 93192782 | 3359 | 3 | 135765 | 2013-09-30 16:59:13 |
+-------------+--------+-------+-------------+---------------------+
1 row in set (0.00 sec)
mysql>
but the row itself only changes a single value (the currentTime). Can anybody explain why the other two fields are not updating?
Sorry, I have solved this myself. The level field is an ENUM and the query specified the new value as a number. Updating the query to the following resulted in the expected results.
mysql> INSERT INTO user_api_skills (characterID,typeID,level,skillpoints) VALUES
(93192782,3359,4,135765) ON DUPLICATE KEY UPDATE level='4', skillpoints=135765,
currentTime=NOW();
By providing a int to the update it updated to the one based number choice of the enum, so in this instance, the 4th choice is '3'.
I knew boolean in mysql as tinyint (1).
Today I see a table with defined an integer like tinyint(2), and also others like int(4), int(6) ...
What does the size means in field of type integer and tinyint ?
The (m) indicates the column display width; applications such as the MySQL client make use of this when showing the query results.
For example:
| v | a | b | c |
+-----+-----+-----+-----+
| 1 | 1 | 1 | 1 |
| 10 | 10 | 10 | 10 |
| 100 | 100 | 100 | 100 |
Here a, b and c are using TINYINT(1), TINYINT(2) and TINYINT(3) respectively. As you can see, it pads the values on the left side using the display width.
It's important to note that it does not affect the accepted range of values for that particular type, i.e. TINYINT(1) still accepts [-128 .. 127].
It means display width
Whether you use tinyint(1) or tinyint(2), it does not make any difference.
I always use tinyint(1) and int(11), I used several mysql clients (navicat, sequel pro).
It does not mean anything AT ALL! I ran a test, all above clients or even the command-line client seems to ignore this.
But, display width is most important if you are using ZEROFILL option, for example your table has following 2 columns:
A tinyint(2) zerofill
B tinyint(4) zerofill
both columns has the value of 1, output for column A would be 01 and 0001 for B, as seen in screenshot below :)
mysql> CREATE TABLE tin3(id int PRIMARY KEY,val TINYINT(10) ZEROFILL);
Query OK, 0 rows affected (0.04 sec)
mysql> INSERT INTO tin3 VALUES(1,12),(2,7),(4,101);
Query OK, 3 rows affected (0.02 sec)
Records: 3 Duplicates: 0 Warnings: 0
mysql> SELECT * FROM tin3;
+----+------------+
| id | val |
+----+------------+
| 1 | 0000000012 |
| 2 | 0000000007 |
| 4 | 0000000101 |
+----+------------+
3 rows in set (0.00 sec)
mysql>
mysql> SELECT LENGTH(val) FROM tin3 WHERE id=2;
+-------------+
| LENGTH(val) |
+-------------+
| 10 |
+-------------+
1 row in set (0.01 sec)
mysql> SELECT val+1 FROM tin3 WHERE id=2;
+-------+
| val+1 |
+-------+
| 8 |
+-------+
1 row in set (0.00 sec)
About the INT, TINYINT... These are different data types, INT is 4-byte number, TINYINT is 1-byte number. More information here - INTEGER, INT, SMALLINT, TINYINT, MEDIUMINT, BIGINT.
The syntax of TINYINT data type is TINYINT(M), where M indicates the maximum display width (used only if your MySQL client supports it).
Numeric Type Attributes.