此前的文章中，我们介绍了 mysql 中的事务和锁机制。 一文讲透 MySQL 的 MVCC 机制 MySQL 锁机制（上） — 全局锁与表级锁 MySQL 锁机制（下） — 细说 InnoDB 行锁（记录锁、间隙锁与临键锁）
在实际业务场景中，经常会有这样的需求：插入一条记录，如果数据表中已经存在该条记录则更新它的部分字段，比如更新update_time或者在某些列上执行累加操作等。参考博客1中介绍了三种在MySQL中避免重复插入记录的方法，本文将在简单介绍这三种用法的基础上，深入分析这其各自存在的问题，最后给出在实际生产环境中对该业务场景的最佳实践。
本篇讲解 Mysql 的「主键」问题，从「为什么」的角度来了解 Mysql 主键相关的知识，并拓展到主键的生成方案问题。再也不怕被问到 Mysql 时只知道 CRUD 了。
行级锁是Mysql中锁定粒度最细的一种锁，表示只针对当前操作的行进行加锁。行级锁能大大减少数据库操作的冲突。其加锁粒度最小，但加锁的开销也最大。有可能会出现死锁的情况。 行级锁按照使用方式分为共享锁和排他锁。
在 第4篇 文章中，我们提到过自增主键，由于自增主键可以让主键索引尽量地保持递增顺序插入，避免了页分裂，因此索引更紧凑。
最近读了一篇关于MYSQL的文章，主要是更深入化的讲解MYSQL的锁机制，写的真是好。但里面细细的读，发现一个问题，索引的问题，一般我们都人为索引是我们查询中的救星，他可以帮助我们摆脱，全表扫描，加快查询的速度，让查询更快减少系统性能上的瓶颈。
结合实例分析了自增值保存在哪里，自增值的修改策略，以及自增值不连续的四个场景，希望对各位小伙伴们有所帮助~
MySQL最常见的集群架构，是一主多从，主从同步，读写分离的架构。通过这种方式，能够扩充数据库的读性能，保证读库的高可用，但此时写库仍然是单点。
在mysql中1075报错的原因是一个字段设置了自动递增，另外一个字段被设置为主键，发生冲突。
疫情期间在家工作时，同事使用了 insert into on duplicate key update 语句进行插入去重，但是在测试过程中发生了死锁现象:
疫情期间在家工作时，同事使用了 insert into on duplicate key update 语句进行插入去重，但是在测试过程中发现了死锁现象:
《原则》原文：但我不敢确信这场转型会顺利，因为我没有经历过这样的事情。我做事的方式是试错：犯错，找出错误原因，总结出新的原则，最终成功。而我觉得应该以同样的态度对待这场转型。
为了大家更好的应对决赛，大赛主办方特此整理一份Q&A（后续会根据赛程中大家所关注的重点问题持续更新），期望对大家有所帮助。
AUTO_INCREMENT=2，表示下一次插入数据时，若需要自动生成自增值，会生成id=2。
还有一种，主键没有自增长，那不复制主键可以吗？答案是不行。因为主键的前提是不能为空，赋值则发生主键冲突，不赋值则引发非空约束（多谢评论区的老哥，以前没有考虑到这种情况）。
mysql在主从复制过程中，由于各种的原因，从服务器可能会遇到执行BINLOG中的SQL出错的情况，在默认情况下，服务器会停止复制进程，不再进行同步，等到用户自行来处理。
文章摘要 在线上环境遇到数据库死锁问题该如何分析并解决问题呢？ 虽然很多童鞋在学数据库课程时都了解数据库隔离级别、死锁和事务等概念，但在测试/线上环境遇到死锁却不一定能够及时分析并解决这类问题。本文主要以作者在测试环境中遇到的一个死锁Case说起，首先还原出现死锁的现场和条件，并结合排查业务应用工程日志、MySQL数据库状态信息等方式，同时给出MySQL锁的基本概念，再通过阅读日志深入定位并分析出现死锁的原因，最后讲下MySQL InnoDB的加锁原理以及如降低死锁发生的机率。 一、 出现死
之前的文章谈到的事故原因，不论是偶发性的查询压力，还是备份，对备库延迟的影响一般是分钟级的，而且在备库恢复正常以后都能够追上来。
对于行级锁与表级锁的折中，开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般
今天在线上遇到一个问题，是由于replace语法导致的主从自增主键不一致问题，这里我模拟了一下，问题能够稳定复现。希望大家后续过程中，不要踩坑
MySQL是一个强大的关系型数据库管理系统，用于存储和管理大量数据。在数据库中，主键约束是一项非常重要的概念，它有助于确保数据的完整性和唯一性。本文将详细介绍MySQL主键约束，包括什么是主键、为什么需要主键、如何创建主键以及主键的最佳实践。
表命名的规则分为3个层级，层级之间通过_分割，例如b_r_identity、d_l_identity。规约为:
常见的MySQL主要有两种结构：Hash索引和B+ Tree索引，我们使用的是InnoDB引擎，默认的是B+树
导语双主架构在MySQL中使用比较普遍，因为有故障后恢复方便的优点。但双写+双向复制的架构业界极少采用，这种架构下可能有什么问题？如何规避这种架构下的数据风险？本文根据实践经验做出了总结。
那就是搞定面试官系列，我会把常见的面试知识通过这个专栏写出来，比如我们常见的 Java、MySQL、Redis、MQ 以及其他的一些技术框架。
最近在重新整理复现MYSQL注入天书,遇到了一条很有意思的报错注入的payload：
提示：公众号展示代码会自动折行，建议横屏阅读 背景 客户发现一个非预期内的锁等待现象，线上频繁出现锁告警，出现问题的case可以简化成以下SQL： # 表结构和表数据CREATE TABLE `tab1` ( `id` bigint unsigned NOT NULL AUTO_INCREMENT, `value` int NOT NULL, `status` tinyint unsigned NOT NULL DEFAULT '1', PRIMARY KEY
在mysql中，索引就是帮助mysql快速找到某条数据的一种数据结构，它是排好序的，独立于mysql表数据之外的。
在上一篇文章中，我和你介绍了几种可能导致备库延迟的原因。你会发现，这些场景里，不论是偶发性的查询压力，还是备份，对备库延迟的影响一般是分钟级的，而且在备库恢复正常以后都能够追上来。
发现，auto_increment并没有+1，而是针对原来的那一条id=4的记录进行了update，因为没有指定其他列(v,extra)的值，所以，update的时候都使用了默认值.
今天在线上发现一个问题，挺有意思的，这里简单记录下。 问题的背景是查看一个Grafana监控的时候，发现监控没有数据了：
大家好，最近粉丝问我这样的一个面试题。MySQL的自增 ID 用完了，怎么办？以下是这个面试题的解决方案。
不记得是在哪里看到说replace into的工作流程是根据主键或者唯一索引来判断记录是否存在,不存在就插入,存在则更新. 然后在框架的orm里面针对mysql的驱动实现了一个replace的方法,而然今天使用的时候出现了问题: mysql> select * from tbl_user; +----+--------+--------+ | id | name | status | +----+--------+--------+ | 1 | eslizn | 0 | +----+----
有一些特殊的insert语句，在执行过程中需要加锁，本文针对这些特殊都insert语句进行展开。
然后插入数据，最后看到，表会自动生成一个AUTO_INCREMENT的值，ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=latin1 ,表示下一次插入数据时，如果需要自动生成自增值，会生成 id=11。
锁是计算机用以协调多个进程间并发访问同一共享资源的一种机制。MySQL中为了保证数据访问的一致性与有效性等功能，实现了锁机制，MySQL中的锁是在服务器层或者存储引擎层实现的。
但事实上，Innodb 引擎实现了行级锁，与只支持表级锁的 MyISAM 相比，这显然能够有效减少锁冲突，这也是 Innodb 最终能够战胜 MyISAM 成为 MySQL 默认存储引擎的一个重要原因。 因此我们在使用中，最为频繁接触到就是行级锁，用好行级锁，减少锁冲突，将有效提升 MySQL 的执行性能，本文我们就来详细介绍一下 Innodb 中的各种行级锁。
如果你用过或了解过MySQL，那你一定知道自增主键了。每个自增id都是定义了初始值，然后按照指定步长增长（默认步长是1）。虽然，自然数是没有上限的，但是我们在设计表结构的时候，通常都会指定字段长度，那么，这时候id就有上限了。既然有上限，就总有被用完的时候，如果id用完了，怎么办呢？今天就一起来学习下吧。
自增主键没有持久化是个比较早的bug，这点从其在官方bug网站的id号也可看出（https://bugs.MySQL.com/bug.php?id=199）。由Peter Zaitsev（现Perco
一 前言 死锁是每个MySQL DBA 都会遇到的技术问题，本文是自己针对死锁学习的一个总结,了解死锁是什么，MySQL如何检测死锁，处理死锁，死锁的案例，如何避免死锁。
关于互联网常见层次架构，由于小编还没整理完毕(预计周四推送)，先来一篇数据库的干货，来满足下大家的胃口，关于mysql的行级锁、表级锁、页级锁的分析，这个在行业应用中设计数据库非常常见的场景。 1常见锁有哪些 在计算机科学中，锁是在执行多线程时用于强行限制资源访问的同步机制，即用于在并发控制中保证对互斥要求的满足。 在 DBMS 中，可以按照锁的粒度把数据库锁分为行级锁(INNODB 引擎)、表级锁(MYISAM 引擎)和页级锁(BDB 引擎 )。 行级锁 行级锁是 Mysql 中锁定粒度最细的一种锁，表
2.InnoDB引擎的自增值，在MySQL5.7及之前的版本，自增值保存在内存里，并没有持久化。每次重启后，第一次打开表的时候，都会去找自增值的最大值max(id)，然后将max(id)+步长作为这个表当前的自增值
在 InnoDB 事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。
如果你用过或了解过MySQL，那你一定知道自增主键了。每个自增id都是定义了初始值，然后按照指定步长增长（默认步长是1）。虽然，自然数是没有上限的，但是我们在设计表结构的时候，通常都会指定字段长度，那么，这时候id就有上限了。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
