mysql表数据装满了怎么办?自增id引发的bug。

国庆节的一个大清早,我就被微信群吵醒了,说是spark实时程序有问题,数据没出来,让我看看。我看了下邮箱,确实有报警信息。我特么,没办法,起床。

1 主键自增id设置不合理引发的bug

首先,我检查了一下应用管理页面,发现资源没有用完,GC也正常,程序正在嗖嗖的跑呢,那怎么会没有今天的数据呢?

看了下日志,error.log里面并没有今天的日志,warn.log里面有sql语句,都很正常,这到底是怎么回事呢?

算了,手动验证一下吧,从warn.log里面复制了一条sql,放在mysql命令行执行,显示:OK 2 row affected.

查询一下,今天还是没有数据,不是已经显示插入成功么,我特么要疯了。

继续插入,报错:

Duplicate entry '4294967295' for key 'PRIMARY'

看一下表结构

show create table `tableName`;
CREATE TABLE `tableName` (
  `id` bigint(11) unsigned NOT NULL AUTO_INCREMENT,
  `count` bigint(20) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

原来是id取无符号整数,数值达到最大4294967295了。

对于int类型的一些基础知识其实上图已经说的很明白了,在这里想讨论下常用的int(11)代表什么意思,很长时间以来我都以为这代表着限制int的长度为11位,直到有天看到篇文章才明白,11代表的并不是长度,而是字符的显示宽度,在字段类型为int时,无论你显示宽度设置为多少,int类型能存储的最大值和最小值永远都是固定的,这里贴一些原文片段。

原因:表结构自增id设置不合理,已经达到上限。

解决办法

1. 增大id最大值,修改为bigint(20).

alter table `hm3_realtime_flash_view_client` modify id bigint(20) auto_increment;

这里需要注意,需要加上auto_increment,否则就不会自增了。

小测试

2. 设置自增id的起始数值,需要比4294967295大1,即4294967296开始。

alter table `tableName` AUTO_INCREMENT=4294967296;

2 MySQL为什么需要一个主键

主键

表中每一行都应该有可以唯一标识自己的一列(或一组列)。

一个顾客可以使用顾客编号列,而订单可以使用订单ID,雇员可以使用雇员ID 或 雇员社会保险号。

主键(primary key) 一列(或一组列),其值能够唯一区分表中的每个行。
唯一标识表中每行的这个列(或这组列)称为主键。没有主键,更新或删除表中特定行很困难,因为没有安全的方法保证只设计相关的行。

虽然并不总是都需要主键,但大多数数据库设计人员都应保证他们创建的每个表有一个主键,以便于以后数据操纵和管理

表中的任何列都可以作为主键,只要它满足一下条件:

 1、任何两行都不具有相同的主键值
 2、每个行都必须具有一个主键值(主键列不允许NULL值)

主键值规范:这里列出的规则是MySQL本身强制实施的。

主键的最好习惯:
除MySQL强制实施的规则外,应该坚持的几个普遍认为的最好习惯为:

 1、不更新主键列的值
 2、不重用主键列的值
 3、不在主键列中使用可能会更改的值(例如,如果使用一个名字作为主键以标识某个供应商,应该供应商合并和更改其名字时,必须更改这个主键)

总之:不应该使用一个具有意义的column(id 本身并不保存表 有意义信息) 作为主键,并且一个表必须要有一个主键,为方便扩展、松耦合,高可用的系统做铺垫。


主键的作用,在于索引。

无特殊需求下Innodb建议使用与业务无关的自增ID作为主键

InnoDB引擎使用聚集索引,数据记录本身被存于主索引(一颗B+Tree)的叶子节点上。这就要求同一个叶子节点内(大小为一个内存页或磁盘页)的各条数据记录按主键顺序存放,因此每当有一条新的记录插入时,MySQL会根据其主键将其插入适当的节点和位置,如果页面达到装载因子(InnoDB默认为15/16),则开辟一个新的页(节点)

1、如果表使用自增主键,那么每次插入新的记录,记录就会顺序添加到当前索引节点的后续位置,当一页写满,就会自动开辟一个新的页。

这样就会形成一个紧凑的索引结构,近似顺序填满。由于每次插入时也不需要移动已有数据,因此效率很高,也不会增加很多开销在维护索引上。

2、 如果使用非自增主键(如果身份证号或学号等),由于每次插入主键的值近似于随机,因此每次新纪录都要被插到现有索引页得中间某个位置:

此时MySQL不得不为了将新记录插到合适位置而移动数据,甚至目标页面可能已经被回写到磁盘上而从缓存中清掉,此时又要从磁盘上读回来,这增加了很多开销,同时频繁的移动、分页操作造成了大量的碎片,得到了不够紧凑的索引结构,后续不得不通过OPTIMIZE TABLE来重建表并优化填充页面。

在使用InnoDB存储引擎时,如果没有特别的需要,请永远使用一个与业务无关的自增字段作为主键。

mysql 在频繁的更新、删除操作,会产生碎片。而含碎片比较大的表,查询效率会降低。此时需对表进行优化,这样才会使查询变得更有效率。

查了一些资料

  • https://www.jianshu.com/p/33b7b6e0a396

  • https://segmentfault.com/a/1190000012479448

  • https://segmentfault.com/q/1010000009807110/a-1020000009810982

猜你可能喜欢

从相亲说起,通俗理解决策树算法

Elasticsearch快速检索之倒排索引算法

(建议收藏)算法工程师常见面试问题及相关资料汇总

Python批量删除mysql中千万级大量数据

经验之谈——自学Python

发布了174 篇原创文章 · 获赞 334 · 访问量 33万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览