每次插入一条数据，其 ID 都是比上一条插入的数据的 ID 大，就算上一条数据被删除。
而SQL全名 Structured Query Language(结构化查询语言)本质上是一种语言，MySQL才是数据库本身。
全局锁主要应用于做全库逻辑备份，这样在备份数据库期间，不会因为数据或表结构的更新，而出现备份文件的数据与预期的不一样。
MyBatis 的真正强大在于它的语句映射，这是它的魔力所在。由于它的异常强大，映射器的 XML 文件就显得相对简单。如果拿它跟具有相同功能的 JDBC 代码进行对比，你会立即发现省掉了将近 95% 的代码。MyBatis 致力于减少使用成本，让开发者能更专注于 SQL 代码。
2、使用bigint(无符号)类型时，每秒插入大量数据，单表数据量依然能够持续存放相当长的时间。
一、Mybatis执行插入语句后可以返回主键ID吗？ 在想写什么内容的时候，正好看到一个基础面试题上有这个问题，就把它记录下来了。 👨💻面试官：你说Mybatis执行插入语句后可以返回主键ID吗？？如果能的话，能否实现一下。 🙋我：当然是可以的，连JDBC都能做到的事情，Mybatis也能做到的。 开始敲代码… 1.1、Mysql数据库设置ID自增情况 <insert id="insertUser" parameterType="com.crush.mybatisplus.entity.User">
面试官：咱们聊聊mysql的自增id。mysql自增id给我们的自增主键定义带来了很大的方便，但是经常mysql的自增id会有不连续情况，能说说什么场景下mysql的id会产生不连续吗我：我以一张表为例来解释一下，我先创建一张表zh_person，这张表包括4个字段，自增id，姓名name，性别sex和身份证号id_no,id_no上有唯一索引，sql如下 CREATE TABLE `zh_person` ( `id` MEDIUMINT(11) NOT NULL AUTO_INCREMENT, `
的时候用版本链readView控制，写的时候加锁。一种是读写都加锁，比如只允许读取最后数据的银行业务。锁又分为共享锁（s锁）和排它锁（x锁），锁的颗粒度分为表锁和行锁，所以当向上表的排他锁的时候，必须里面的行没有上x锁或者s锁，当然不是遍历所有行，于是在上行锁的时候，会有一个is和ix的锁，代表当前表上了行锁。
哈喽，好久没更新啦。因为最近在面试。用了两周时间准备，在 3 天之内拿了 5 个 offer，最后选择了广州某互联网行业独角兽 offer，昨天刚入职。这几天刚好整理下在面试中被问到有意思的问题，也借此机会跟大家分享下。
看到这个问题，我想起当初玩魔兽世界的时候，25H难度的脑残吼的血量已经超过了21亿，所以那时候副本的BOSS都设计成了转阶段、回血的模式，因为魔兽的血量是int型，不能超过2^32大小。
MySQL 里字段的属性很多，对性能来说，影响也是可大可小，所以针对其属性这一块有必要进行一次探究。
可以看到表定义中出现了AUTO_INCREMENT=2，表示下一次插入数据时如果需要自动生成自增值，那么id便是2。
使用Docker部署elasticsearch docker下一键启动es，可根据需要的版本号对语句做修改
自增id是整型字段，我们常用int类型来定义增长id，而int类型有上限 即增长id也是有上限的。
在实际业务场景中，经常会有这样的需求：插入一条记录，如果数据表中已经存在该条记录则更新它的部分字段，比如更新update_time或者在某些列上执行累加操作等。参考博客1中介绍了三种在MySQL中避免重复插入记录的方法，本文将在简单介绍这三种用法的基础上，深入分析这其各自存在的问题，最后给出在实际生产环境中对该业务场景的最佳实践。
首先我们一般创建 MySQL 数据表的时候，大部分情况下会创建一个自增主键ID 的字段，可能你的建表语句如下：
《MySQL自增ID，居然大部分人都搞错了？》中的作业题，有少量答对的人，但原理讲得不透，今天简单说下作业题中的答案，以及相关知识点。 作业题是这样的： drop table t1; create table t1( id int not null auto_increment, name varchar(10) unique, count int default 0, primary key(id), index(name) )engine=innodb; ins
2.InnoDB引擎的自增值，在MySQL5.7及之前的版本，自增值保存在内存里，并没有持久化。每次重启后，第一次打开表的时候，都会去找自增值的最大值max(id)，然后将max(id)+步长作为这个表当前的自增值
上一篇文章[服务端篇]提到本项目的数据库采用了关系型的 MySQL，那么，本文将基于 MySQL 聊聊本项目的数据库设计。
结合实例分析了自增值保存在哪里，自增值的修改策略，以及自增值不连续的四个场景，希望对各位小伙伴们有所帮助~
然后插入数据，最后看到，表会自动生成一个AUTO_INCREMENT的值，ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=latin1 ,表示下一次插入数据时，如果需要自动生成自增值，会生成 id=11。
昨天是七夕节嘛，晚上陪女朋友吃饭去啦，然后回来肝文的时候，写着写着发现已经过晚上 12 点了，本来今天这篇是想昨天发的，可惜没赶着。
最常见的方式就是为字段设置主键或唯一索引，当插入重复数据时，抛出错误，程序终止，但这会给后续处理带来麻烦，因此需要对插入语句做特殊处理，尽量避开或忽略异常，下面我简单介绍一下，感兴趣的朋友可以尝试一下：
之前有碰到过开发同事指出一张InnoDB表的自增列 AUTO_INCREMENT 值莫明的变大，由于这张表是通过MySQLdump导出导入的。
AUTO_INCREMENT=2，表示下一次插入数据时，若需要自动生成自增值，会生成id=2。
今天是《MySQL核心知识》专栏的第7章，今天为大家系统的讲讲MySQL中的插入、更新、删除语句，希望通过本章节的学习，小伙伴们能够举一反三，彻底掌握MySQL中的各种插入、更新、删除语句。好了，开始今天的正题吧。
上篇教程我们介绍了 MySQL 的安装以及如何在客户端连接并管理 MySQL 数据库，今天我们来简单过一下日常常用的 SQL 语句，以 phpMyAdmin 作为 GUI 工具为例进行演示。
《InnoDB自增键基础知识测试》中的四道测试题，全答对的朋友少之又少，为了讲清楚InnoDB自增键，今天先系统性讲讲，什么是插入，如何插入。
数据库使用锁是为了支持对共享资源的并发访问，同时保证数据的完整性和一致性。其中，MySQL在Server层和InnoDB引擎设计了多种类型的锁机制，用于实现不同场景下的并发控制，下面我们分析一下这些锁的定义和使用场景。
mysql自增主键设置 在数据库应用中，经常希望在每次插入新纪录时，系统自动生成字段的主键值。可以通过为表主键添加AUTO_INCREMENT关键字来实现。 默认情况下，在MYSQL中AUTO_INCREMENT的初始值是1，每新增一条记录，字段值自动加1.一个表只能有一个字段属用AUTO_INCREMENT约束，且该字段必须为主键的一部分。AUTO_INCREMENT约束的字段可以是任何整数类型(TINTINT、SMALLINT、INT、BIGINT等) 设置表的属性值自动增加的语法规则如下: 字段名
1.如果表名后没有字段列表，values后的值列表中的个数和表字段个数一致，并且值列表的顺序和字段列表的顺序一致。一般如果主键列自增，不显示的给自增列赋值；
其实上面这些问题，我最早想法是，每个问题都可以啰嗦出一篇文章。后来由于良心发现，烟哥就决定用一篇文章将这些问题都讲明白。 当然，我给的回答可能并非标准答案，毕竟是自己的一些工作总结。各位读者有更好的回答，也欢迎交流！
在 第4篇 文章中，我们提到过自增主键，由于自增主键可以让主键索引尽量地保持递增顺序插入，避免了页分裂，因此索引更紧凑。
在mysql中有多种自增id，除了我们日常开发中经常使用的自增主键外，还有一些其他的自增id，主要是mysql内部为了辅助其正常运行而使用的。
大家好，我是捡田螺的小男孩。本文将跟大家聊聊InnoDB的锁。本文比较长，包括一条SQL是如何加锁的，一些加锁规则、如何分析和解决死锁问题等内容，建议耐心读完，肯定对大家有帮助的。
哈希表是一种以键-值（key-value）存储数据的结构，只要输入待查找的值即key，就可以找到其对应的值即Value，时间复杂度为O(1)，但是容易发生哈希冲突，当发生冲突时，常用开放地址法、拉链法、再散列法解决
小伙伴想精准查找自己想看的MySQL文章？喏 → MySQL专栏目录 | 点击这里
数据库使用锁是为了支持更好的并发，提供数据的完整性和一致性。InnoDB是一个支持行锁的存储引擎，锁的类型有：
MySQL 里有很多自增的 id，每个自增 id 都是定义了初始值，然后不停地往上加步长。虽然自然数是没有上限的，但是在计算机里，只要定义了表示这个数的字节长度，那它就有上限。比如，无符号整型 (unsigned int) 是 4 个字节，上限就是 2^32-1。
本栏目Java开发岗高频面试题主要出自以下各技术栈：Java基础知识、集合容器、并发编程、JVM、Spring全家桶、MyBatis等ORMapping框架、MySQL数据库、Redis缓存、RabbitMQ消息队列、Linux操作技巧等。
如果您遇到全球少数的MySQL顾问之一，请他审核您的SQL语句和表结构设计，我相信他会告诉您一些有关好的主键设计的重要性。特别是对InnoDB，我相信他已经想您解释了索引合并和页分裂。这两个概念与性能密切相关，在设计任意索引（不仅仅是主键）时都应该考虑这方面因素。
好了，锁相关内容的最后一篇文章了。其实最核心的内容，表锁、行锁、读锁、写锁、间隙锁这些重要的内容我们都已经学习过了，特别是间隙锁，是不是感觉非常复杂。放心，今天的内容就比较轻松了。
通常情况下，当访问某张表的时候，读取者首先必须获取该表的锁，如果有写入操作到达，那么写入者一直等待读取者完成操作（查询开始之后就不能中断，因此允许读取者完成操作）。当读取者完成对表的操作的时候，锁就会被解除。如果写入者正在等待的时候，另一个读取操作到达了，该读取操作也会被阻塞（block），因为默认的调度策略是写入者优先于读取者。当第一个读取者完成操作并解放锁后，写入者开始操作，并且直到该写入者完成操作，第二个读取者才开始操作。因此：要提高MySQL的更新/插入效率，应首先考虑降低锁的竞争，减少写操作的等待时间。 （本专题在后面会讨论表设计的优化）本篇，要讲的优化是增删改。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
