Let's say we have a simple table of 2 columns with two scenarios.
With ID column of length 10
CREATE TABLE `members` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(50) NOT NULL,
)
With ID column of length 1
CREATE TABLE `members` (
`id` int(1) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(50) NOT NULL,
)
Can I define the length of column ID by 1 if I don't need the leading zeros in the ID column?
I don't have an idea where the leading zeros are helpful and what are the cons if I define the length of the integer column by 1 if there is no need for leading zeros.
If you don't need leading zeroes, then simply do not use the ZEROFILL column option, which I see is already absent from your create table statement.
The "length" of an integer is meaningless except for display. It does not affect the storage size of the integer, or the maximum value that can be stored in it. The length is optional, and I always omit it.
Example:
CREATE TABLE `members` (
`id` int unsigned NOT NULL AUTO_INCREMENT,
...
This has been the source of confusion for MySQL users for many years.
Finally in MySQL 8.0, they stopped outputting this misleading syntax when you use SHOW CREATE TABLE. Use of the integer length is discouraged.
The short answer is: You can set the zerofill length to 1 if you absolutely have no use of it. However, sometimes you may want your numbers to be neatly aligned . e.g Instead of displaying ID values from 1 all the way up to 9999, defining an int(4) zerofill makes the values show up from 0001 to 9999. That could be helpful in certain formal scenarios.
Looking at integer values. It seems that setting the Unsigned attribute overrides the field length.
Traditionally, MYSQL translates the BOOLEAN alias to TINYINT(1).
According to the inter-webs, as of MySQL 8.0.17, display width specifications for integer data types have been deprecated. There are two exceptions to this which include: TINYINT(1)
However, there is a bug (known or unknown IDK) where when I set UNSIGNED on any TINYINT value, the display length is dropped.
Steps to reproduce:
Create a table with a field intended to be used as a BOOLEAN;
CREATE TABLE users (
id int unsigned NOT NULL AUTO_INCREMENT ,
user_name varchar(50) NOT NULL,
password varchar(255) NOT NULL,
is_active tinyint(1) NOT NULL DEFAULT '1',
PRIMARY KEY (id),
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
Observe that the display length on TINYINT(1) is in fact set.
Alter the table to make is_active an UNSIGNED value:
ALTER TABLE users
CHANGE COLUMN is_active is_active TINYINT(1) UNSIGNED NOT NULL DEFAULT '1' ;
Observe that TINYINT no longer has a display length.
List item
Expected result:
I argue that the correct field attribute for a "BOOLEAN" would be unsigned since your options would be 0 or 1. Not negatives. Therefore I would expect that the UNSIGNED behavior for TINYINT(1) be identical to the signed behavior, and field display length would be set / retained.
Question:
Has anyone else encountered this behavior? Any ideas on a work around? Right now I am sticking with signed tinyint's...
I have a table created like so:
CREATE TABLE `my_table` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`info` varchar(50) DEFAULT NULL,
`some_more_info` smallint(5) unsigned NOT NULL
PRIMARY KEY (`id`),
KEY `my_index` (`some_more_info`,`info`(24)),
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8
My question is about the second key called my_index. What does the "(24)" size limit mean? The actual size of the column is 50, but the index is only 24 characters.
Does this mean that MySQL indexes only the first 24 characters of the column info?
In short, yes, the first 24 characters are taken into consideration to build the BTree index. Indexing limits are assigned to text types such as varchar and text, as they don't affect numeric precision.
Yes.
The entire description about the index length can be found here:
http://dev.mysql.com/doc/refman/5.0/en/create-index.html
Prefix lengths are given in characters for nonbinary string types and
in bytes for binary string types. That is, index entries consist of
the first length characters of each column value for CHAR, VARCHAR,
and TEXT columns, and the first length bytes of each column value for
BINARY, VARBINARY, and BLOB columns.
Also you create query has/had some extra ,'s.
Strange problem I can't seem to get my head around. I have a table in a MySQL database with the following structure...
CREATE TABLE IF NOT EXISTS `tblbaseprices` (
`base_id` bigint(11) NOT NULL auto_increment,
`base_size` int(10) NOT NULL default '0',
`base_label` varchar(250) default NULL,
`base_price_1a` float default NULL,
`base_price_2a` float default NULL,
`base_price_3a` float default NULL,
`base_price_1b` float default NULL,
`base_price_2b` float default NULL,
`base_price_3b` float default NULL,
`site_id` int(11) default NULL,
PRIMARY KEY (`base_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=134 ;
The last base_id I have in there is 132. I assume a couple of records have been deleted to auto_increment is set to 134, as you can see about. I am trying to run the following SQL statement, and when I do, I get the error "Duplicate entry '2147483647' for key 1".
INSERT INTO tblbaseprices (site_id, base_size, base_price_1a, base_price_2a, base_price_3a, base_price_4a) VALUES ('', '', '', '', '', '')
Does anybody have any ideas?
Many thanks!
2^31 − 1 = 2,147,483,647
The number 2,147,483,647 is ... the maximum value for a 32-bit signed integer in computing
2147483647 is the largest int value for mysql. Just change the type from int to bigint.
With you code I got this error - Unknown column 'base_price_4a' in 'field list'.
It means that you are trying to insert into another table (maybe in another schema), and that table has primary key INT and AUTO_INCREMENT=2147483647.
you've hit the 32-bit integer limit, thus preventing the auto increment from incrementing. switching your pk to bigint with a higher column length should fix the issue.
Also, if your PK is never going to be negative, switching to an unsigned int should give you more space.
Try changing the auto_increment column to bigint instead of int, then the max value would be '9223372036854775807' or even '18446744073709551615' if you make it unsigned (no values below 0).
Change your Auto_Increment to the last id in the column so it is continued where it left off.
Be sure you do not delete auto_increment, otherwise it will continue to produce the error.
You're inserting empty strings into numerical columns. As far as I can see, you're also inserting into a column that does not exist in the schema. My guess is this has something to do with your error.
signed and unsigned issue
alter table tblbaseprices
modify column site_id int(10) unsigned NOT NULL;
reference - http://dev.mysql.com/doc/refman/5.0/en/numeric-type-overview.html
make sure unsigned for foreign key (in this case could be the site_id)
it could be caused by trigger,
there is no int(11), the max it can go is int(10)
there is no need to allow negative value for ID
to be consistently using same data type for primary key
Today I got the error duplicate key 2147483647
I think it came out when I tried to insert a record into database from PhpMyAdmin, while typing, I also tried to enter the key value and it was eider lower than the current Next autoindex or I tried to type something like 99999999999999 as the key field, and that caused it to set Next autoindex to maximum
Anyway, the erorr was caused because Next autoindex was 2147483647 for that table.
My table was empty so I fixed it by this query:
ALTER TABLE table_name AUTO_INCREMENT = 0
if your table contains data, then replace 0 with your maximum key plus 1
it's a database issue. check your phpmyadmin > your DB > structure, your primary key should be setted in "bigint", not just "int"
CREATE TABLE IF NOT EXISTS `tblbaseprices` (
`base_id` bigint(11) NOT NULL auto_increment,
`base_size` int(10) NOT NULL default '0',
`base_label` varchar(250) default NULL,
`base_price_1a` float default NULL,
`base_price_2a` float default NULL,
`base_price_3a` float default NULL,
`base_price_1b` float default NULL,
`base_price_2b` float default NULL,
`base_price_3b` float default NULL,
`site_id` int(11) default NULL,
PRIMARY KEY (`base_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=134 ;
A good explanation of that is here: http://realtechtalk.com/Duplicate_entry_2147483647_for_key_PRIMARY_MySQL_Error_Solution-2015-articles
Essentially you are trying to insert a value larger than the maximum size an INT supports which is literally the number being given to you in the error.
If you are importing data than one of the fields contains a larger value than the INT size. You could also modify your table to be a BIGINT which would take care of the issue as well (of course at the cost of extra disk space).
A common reason is that you are using some script generating large/random numbers. You should add some check to make sure the size is the same or lower than that maximum INT size of 2147483647 and you'll be good to go.
Duplicate entry '57147-2147483647' for key 'app_user' [ INSERT INTO user_lookup (user_id, app_id, app_user_id, special_offers, ip_address) VALUES ('2426569', '57147', '4009116545', 1, 1854489853) ]
I am using a VARCHAR as my primary key. I want to auto increment it (base 62, lower/upper case, numbers), However, the below code fails (for obvious reasons):
CREATE TABLE IF NOT EXISTS `campaign` (
`account_id` BIGINT(20) NOT NULL,
`type` SMALLINT(5) NOT NULL,
`id` VARCHAR(16) NOT NULL AUTO_INCREMENT PRIMARY KEY
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
however, this works:
CREATE TABLE IF NOT EXISTS `campaign` (
`account_id` BIGINT(20) NOT NULL,
`type` SMALLINT(5) NOT NULL,
`id` VARCHAR(16) NOT NULL PRIMARY KEY
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
What is the best way to keep track of incrementation of 'id' myself? (Since auto_increment doesn't work). Do i need to make another table that contains the current iteration of ID? Or is there a better way to do this?
EDIT: I want to clarify that I know that using INT is a auto_increment primary key is the logical way to go. This question is in response to some previous dialogue I saw. Thanks
you have to use an INT field
and translate it to whatever format you want at select time
example of a solution to your problem:
create a file with a unique number and then increment with a function.
the filename can be the prefix and the file binary content represent a number.
when you need a new id to the reg invoque the function
Example
String generateID(string A_PREFIX){
int id_value = parsetoInt(readFile(A_PREFIX).getLine())
int return_id_value = id_value++
return return_id_value
}
where "A_PREFIX-" is the file name wich you use to generate the id for the field.
Or just create a sequence and maintain the pk field using the sequence to generate the primary key value with nextval function. And if perf is an issue, use cache on sequence.
But as others have stated, this is sub-optimal, if your primary key contains a numbered sequence then it's better to use int and auto-increment.
I don't see a use case where pk has to auto-increment but be a varchar data type, it doesn't make sense.
Assuming that for reasons external to the database, you do need that varchar column, and it needs to autoIncrement, then how about creating a trigger that grabs the existing autoIncrement value and uses Convert() to convert that value into a VarChar, dropping the VarChar into the field of interest. As mentioned in a previous answer, you could concatenate the table-name with the new varChar value, if there is some advantage to that.