在MySQL中,int类型通常占用4个字节,而bigint类型占用8个字节。这意味着,如果将主键ID从int类型改成bigint类型,每个记录将多占用4个字节的存储空间。 3. 性能影响 将主键ID从int类型改成bigint类型可能会对数据库性能产生一定影响。由于bigint类型占用更多的存储空间,索引的大小也会相应增加,这可能会导致索引的查找...
TINYINT:1个字节,范围为-128到127,适用于小规模数据。 SMALLINT:2个字节,范围为-32768到32767,适用于中等规模数据。 MEDIUMINT:3个字节,范围为-8388608到8388607,适用于大规模数据。 INT:4个字节,范围为-2147483648到2147483647,适用于大规模数据。 BIGINT:8个字节,范围为-9223372036854775808到9223372036854775807,适用...
推荐使用int,bigint 无符号做自增键禁止使用uuid做主键 关于主键的类型选择上最常见的争论是用整型还是字符型的问题，关于这个问题《高性能MySQL》一书中有明确论断：整数通常是标识列的最好选择，因为它很快且可以使用AUTO_INCREAMENT,如果可能，应该避免使用字符串类型作为标识列，因为很消耗空间，且通常比数字类型慢...
在MySQL 中,一般会把主键设置成 int 型。而 MySQL 中 int 型占用 4 个字节,作为有符号位的话范围就是 [-231,231-1],也就是[-2147483648,2147483647];无符号位的话最大值就是 2^32-1,也就是 4294967295。随着数据量的增加int变更为bigint 无符号位的话最大值就是 2^64-1,这样的单表能用很多年了。
test_long:以bigint作为主键。 test_int:以int作为主键。 三个表的字段,除了主键ID 分别采用varchar,bigint 和自动增长int不同外,其他三个字段都为 varchar 36位 另外,建表时使用InnoDB存储引擎,并且向数据库中插入100W条数据,用以测试。 压测信息 表类型:InnoDB 数据量:100W条 数据库: 主键采用uuid 32位 运...
在MySQL8.0中还是推荐使用无符号的int, bigint做主键,如果要使用uuid可以建一个唯一索引 MySQL和Java两者默认生成的uuid是version 1格式:datetime|mac地址,因为高低位顺序乱了,造成顺序乱掉,可以使用MySQL的函数uuid_to_bin(@uuid,1) , bin_to_uuid(@uuid,1)进行调整转换,实现有序化 ...
但是不知道大家考虑过没有，我们定义的int或者bigint都是有长度上限的。如果表中的最大记录id超过这个上限值，MySQL会发生什么错误呢？从上图可以看出，tinyint和smallint的范围都比较小，我们一般不会将其作为主键id的类型。如果主键采用有符号int类型进行自增，那么id的最大值是2147483647，如果采用无符号int类型进行...
因为代码中id字段是声明为int类型,直接将数据库的id改为bigint的话,程序会报错,所以需要先改代码,上线后才能改表。 代码顺利上线,改表成功后,通过流水表的记录将用户积分修复为正确数据。 二、关于主键id自增 对于insert、insert on duplicate key update、insert ignore语句,如果没有指定主键id字段值,就算没有插入...
如果用身份证号做主键,那么每个二级索引的叶子节点占用约 20 个字节,而如果用整型做主键,则只要 4 个字节,如果是长整型(bigint)则是 8 个字节。显然,主键长度越小,普通索引的叶子节点就越小,普通索引占用的空间也就越小。所以,从性能和存储空间方面考量,自增主键往往是更合理的选择。 有没有什么场景适合用...
直接改肯定不行，得先把id删了，然后再创建一个字段id，删除字段时先把主键去掉