1.MySQL锁、源码事务隔离级别、索引MVCC机制详解、源码间隙锁、索引死锁等
2.mysql innodb和myisam区别
3.数据库｜一文教你解决on duplicate key update引发的源码索引数据不一致问题
4.面试突击：MVCC 和间隙锁有什么区别？
5.mysql的两种存储引擎区别
6.对于MVCC的理解

MySQL锁、事务隔离级别、索引受控源是源码MVCC机制详解、源码间隙锁、索引死锁等

       锁是源码计算机协调多个进程或线程并发访问某一资源的机制。在数据库中，索引除了传统的源码计算资源（如CPU、RAM、索引I/O等）的源码争用以外，数据也是索引一种供需要用户共享的资源。如何保证数据并发访问的源码一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。

       锁分类可以从性能上分为乐观锁和悲观锁。乐观锁通过rowversion比较数据的版本号，如果和最初数据不一致，则返回错误信息给用户，让用户决定下一步怎么办。悲观锁则是修改数据前先加锁锁定，防止其他人修改。从对数据库操作上分，读锁（共享锁）针对同一份数据，多个读操作可以同时进行而不会互相影响。写锁（排它锁）在当前写操作没有完成前，会阻断其他写锁和读锁。从对数据操作的源码时代前段颗粒上分，表锁每次操作锁住整张表，行锁每次操作锁住一行数据。

       事务是由一组SQL语句组成的逻辑处理单元，具有原子性、一致性、隔离性和持久性这四个属性。原子性意味着事务是一个原子操作单元，其对数据的修改，要么全执行，要么全不执行。一致性要求在事务开始和完成时，数据必须保持一致状态。隔离性保证了事务在不受外部并发操作影响的“独立”环境执行。持久性意味着事务完成之后，它对数据的修改是永久性的，即使出现系统故障也能够保持。

       并发事务带来的问题包括更新丢失、脏读、不可重复读和幻读。更新丢失发生在两个或多个事务选择同一行，然后基于最初选定的值更新该行时。脏读是一个事务正在对一条记录做修改，在这个事务完成并提交前，这条记录的数据就处于不一致的状态。不可重复读发生在一个事务内，在读取某些数据后的某个时间，再次读取以前读过的数据，却发现其读出的数据已经发生了改变、或某些记录已经被删除了。yyy指标源码幻读是指一个事务在未结束按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据。

       为了解决事务并发带来的问题，数据库系统提供了四个事务隔离级别：读未提交、读已提交、可重复读和顺序读（可串行化）。读未提交允许脏读取，读已提交解决了“脏读”，但解决不了“不可重复读”。可重复读解决了“脏读”和“不可重复读”，但解决不了“幻读”。顺序读（可串行化）是解决上述所有情况的最严格的事务隔离级别。

       在实战中，通过读锁和写锁的使用，可以观察到MyISAM在执行查询语句（SELECT）前自动给涉及的所有表加读锁，在执行增删改操作前自动给涉及的表加写锁。读锁会阻塞写，但不阻塞读；写锁会阻塞读和写。读未提交允许脏读取，读已提交解决了脏读，但不解决不可重复读。可重复读解决了脏读和不可重复读，但引入了MVCC机制，确保了事务处理过程中数据的一致性。顺序读（可串行化）级别则通过确保事务的顺序执行，解决了上述所有并发问题。

       MVCC（多版本并发控制）机制是InnoDB存储引擎中的一种高效并发控制技术。在MVCC中，事务在读取数据时，AutoGPT 源码解析系统为每个版本的数据创建了一个版本链，这样在查询时，系统可以基于当前事务的读视图（read view）来访问历史版本的数据，避免了在多个事务并发读取时的冲突。通过分析MVCC机制下的读视图和版本链，可以深入理解MVCC如何在保证并发的同时，确保数据的一致性和完整性。

       间隙锁是一种特殊类型的锁，用于解决幻读问题。通过在特定范围内添加间隙锁，可以阻止其他会话在该范围内的间隙中插入或修改任何数据，从而避免了幻读现象。

       行锁升级表锁的情况通常发生在对非索引字段进行更新时。为了减少这种情况的发生，可以通过合理设计索引，尽量缩小锁的范围，以及控制事务的大小，减少锁定资源量和时间长度来优化。

       死锁是多个事务等待对方释放锁的情况，大多数情况下，MySQL可以自动检测并回滚产生死锁的那个事务。但在某些情况下，MySQL可能无法自动检测死锁，因此需要在设计时避免死锁的发生。

       最后，对于优化建议，包括尽可能让所有数据检索都通过索引来完成，避免无索引行锁升级为表锁，合理设计索引以缩小锁的剪映 源码范围，尽可能减少检索条件范围以避免间隙锁，以及控制事务大小，尽可能将涉及锁定的SQL语句放在事务的最后执行，使用较低级别的事务隔离。

mysql innodb和myisam区别

       InnoDB和MyISAM是很多人在使用MySQL时最常用的两个表类型，这两个表类型各有优劣，5.7之后就不一样了

       1、事务和外键

       InnoDB具有事务，支持4个事务隔离级别，回滚，崩溃修复能力和多版本并发的事务安全，包括ACID。如果应用中需要执行大量的INSERT或UPDATE操作，则应该使用InnoDB，这样可以提高多用户并发操作的性能

       MyISAM管理非事务表。它提供高速存储和检索，以及全文搜索能力。如果应用中需要执行大量的SELECT查询，那么MyISAM是更好的选择

       2、全文索引

       Innodb不支持全文索引，如果一定要用的话，最好使用sphinx等搜索引擎。myisam对中文支持的不是很好

       ä¸è¿‡æ–°ç‰ˆæœ¬çš„Innodb已经支持了

       3、锁

       mysql支持三种锁定级别，行级、页级、表级;

       MyISAM支持表级锁定，提供与 Oracle 类型一致的不加锁读取(non-locking read in SELECTs)

       InnoDB支持行级锁，InnoDB表的行锁也不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，注意间隙锁的影响

       ä¾‹å¦‚update table set num=1 where name like “%aaa%”

       4、存储

       MyISAM在磁盘上存储成三个文件。第一个文件的名字以表的名字开始，扩展名指出文件类型， .frm文件存储表定义，数据文件的扩展名为.MYD，  索引文件的扩展名是.MYI

       InnoDB，基于磁盘的资源是InnoDB表空间数据文件和它的日志文件，InnoDB 表的大小只受限于操作系统文件的大小

       æ³¨æ„ï¼šMyISAM表是保存成文件的形式，在跨平台的数据转移中使用MyISAM存储会省去不少的麻烦

       5、索引

       InnoDB（索引组织表）使用的聚簇索引、索引就是数据，顺序存储，因此能缓存索引，也能缓存数据

       MyISAM（堆组织表）使用的是非聚簇索引、索引和文件分开，随机存储，只能缓存索引

       6、并发

       MyISAM读写互相阻塞：不仅会在写入的时候阻塞读取，MyISAM还会在读取的时候阻塞写入，但读本身并不会阻塞另外的读

       InnoDB è¯»å†™é˜»å¡žä¸Žäº‹åŠ¡éš”离级别相关

       7、场景选择

       MyISAM

       ä¸éœ€è¦äº‹åŠ¡æ”¯æŒï¼ˆä¸æ”¯æŒï¼‰

       å¹¶å‘相对较低（锁定机制问题）

       æ•°æ®ä¿®æ”¹ç›¸å¯¹è¾ƒå°‘（阻塞问题），以读为主

       æ•°æ®ä¸€è‡´æ€§è¦æ±‚不是非常高

       å°½é‡ç´¢å¼•ï¼ˆç¼“存机制）

       è°ƒæ•´è¯»å†™ä¼˜å…ˆçº§ï¼Œæ ¹æ®å®žé™…需求确保重要操作更优先

       å¯ç”¨å»¶è¿Ÿæ’入改善大批量写入性能

       å°½é‡é¡ºåºæ“ä½œè®©insert数据都写入到尾部，减少阻塞

       åˆ†è§£å¤§çš„操作，降低单个操作的阻塞时间

       é™ä½Žå¹¶å‘数，某些高并发场景通过应用来进行排队机制

       å¯¹äºŽç›¸å¯¹é™æ€çš„数据，充分利用Query Cache可以极大的提高访问效率

       MyISAM的Count只有在全表扫描的时候特别高效，带有其他条件的count都需要进行实际的数据访问

       InnoDB 

       éœ€è¦äº‹åŠ¡æ”¯æŒï¼ˆå…·æœ‰è¾ƒå¥½çš„事务特性）

       è¡Œçº§é”å®šå¯¹é«˜å¹¶å‘有很好的适应能力，但需要确保查询是通过索引完成

       æ•°æ®æ›´æ–°è¾ƒä¸ºé¢‘繁的场景

       æ•°æ®ä¸€è‡´æ€§è¦æ±‚较高

       ç¡¬ä»¶è®¾å¤‡å†…存较大，可以利用InnoDB较好的缓存能力来提高内存利用率，尽可能减少磁盘 IO

       ä¸»é”®å°½å¯èƒ½å°ï¼Œé¿å…ç»™Secondary index带来过大的空间负担

       é¿å…å…¨è¡¨æ‰«æï¼Œå› ä¸ºä¼šä½¿ç”¨è¡¨é”

       å°½å¯èƒ½ç¼“存所有的索引和数据，提高响应速度

       åœ¨å¤§æ‰¹é‡å°æ’入的时候，尽量自己控制事务而不要使用autocommit自动提交

       åˆç†è®¾ç½®innodb_flush_log_at_trx_commit参数值，不要过度追求安全性

       é¿å…ä¸»é”®æ›´æ–°ï¼Œå› ä¸ºè¿™ä¼šå¸¦æ¥å¤§é‡çš„数据移动

       8、其它细节

       1）InnoDB 中不保存表的具体行数，注意的是，当count(*)语句包含 where条件时，两种表的操作是一样的

       2）对于AUTO_INCREMENT类型的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中，可以和其他字段一起建立联合索引， 如果你为一个表指定AUTO_INCREMENT列，在数据词典里的InnoDB表句柄包含一个名为自动增长计数器的计数器，它被用在为该列赋新值。自动增长计数器仅被存储在主内存中，而不是存在磁盘

       3）DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除

       4）LOAD TABLE FROM MASTER操作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对于使用的额外的InnoDB特性(例如外键)的表不适用

       5）如果执行大量的SELECT，MyISAM是更好的选择，如果你的数据执行大量的INSERT或UPDATE，出于性能方面的考虑，应该使用InnoDB表

       7、为什么MyISAM会比Innodb 的查询速度快

       InnoDB åœ¨åšSELECT的时候，要维护的东西比MYISAM引擎多很多；

       1）InnoDB è¦ç¼“存数据和索引，MyISAM只缓存索引块，这中间还有换进换出的减少

       2）innodb寻址要映射到块，再到行，MyISAM记录的直接是文件的OFFSET，定位比INNODB要快

       3）InnoDB è¿˜éœ€è¦ç»´æŠ¤MVCC一致；虽然你的场景没有，但他还是需要去检查和维护

       MVCC ( Multi-Version Concurrency Control )多版本并发控制

       InnoDB ï¼šé€šè¿‡ä¸ºæ¯ä¸€è¡Œè®°å½•æ·»åŠ ä¸¤ä¸ªé¢å¤–的隐藏的值来实现MVCC，这两个值一个记录这行数据何时被创建，另外一个记录这行数据何时过期（或者被删除）。但是InnoDB并不存储这些事件发生时的实际时间，相反它只存储这些事件发生时的系统版本号。这是一个随着事务的创建而不断增长的数字。每个事务在事务开始时会记录它自己的系统版本号。每个查询必须去检查每行数据的版本号与事务的版本号是否相同。让我们来看看当隔离级别是REPEATABLE READ时这种策略是如何应用到特定的操作的

       SELECT InnoDB必须每行数据来保证它符合两个条件

       1、InnoDB必须找到一个行的版本，它至少要和事务的版本一样老(也即它的版本号不大于事务的版本号)。这保证了不管是事务开始之前，或者事务创建时，或者修改了这行数据的时候，这行数据是存在的。

       2、这行数据的删除版本必须是未定义的或者比事务版本要大。这可以保证在事务开始之前这行数据没有被删除。

       8、mysql性能讨论

       MyISAM最为人垢病的缺点就是缺乏事务的支持

       InnoDB 的磁盘性能很令人担心

       MySQL 缺乏良好的 tablespace 

       ä¸¤ç§ç±»åž‹æœ€ä¸»è¦çš„差别就是Innodb 支持事务处理与外键和行级锁.而MyISAM不支持.所以MyISAM往往就容易被人认为只适合在小项目中使用。

       æˆ‘作为使用MySQL的用户角度出发，Innodb和MyISAM都是比较喜欢的，但是从我目前运维的数据库平台要达到需求：.9%的稳定性，方便的扩展性和高可用性来说的话，MyISAM绝对是我的首选。

       åŽŸå› å¦‚下：

       1、首先我目前平台上承载的大部分项目是读多写少的项目，而MyISAM的读性能是比Innodb强不少的。

       2、MyISAM的索引和数据是分开的，并且索引是有压缩的，内存使用率就对应提高了不少。能加载更多索引，而Innodb是索引和数据是紧密捆绑的，没有使用压缩从而会造成Innodb比MyISAM体积庞大不小。

       3、从平台角度来说，经常隔1，2个月就会发生应用开发人员不小心update一个表where写的范围不对，导致这个表没法正常用了，这个时候MyISAM的优越性就体现出来了，随便从当天拷贝的压缩包取出对应表的文件，随便放到一个数据库目录下，然后dump成sql再导回到主库，并把对应的binlog补上。如果是Innodb，恐怕不可能有这么快速度，别和我说让Innodb定期用导出xxx.sql机制备份，因为我平台上最小的一个数据库实例的数据量基本都是几十G大小。

       4、从我接触的应用逻辑来说，select count(*) 和order by 是最频繁的，大概能占了整个sql总语句的%以上的操作，而这种操作Innodb其实也是会锁表的，很多人以为Innodb是行级锁，那个只是where对它主键是有效，非主键的都会锁全表的。

       5、还有就是经常有很多应用部门需要我给他们定期某些表的数据，MyISAM的话很方便，只要发给他们对应那表的frm.MYD,MYI的文件，让他们自己在对应版本的数据库启动就行，而Innodb就需要导出xxx.sql了，因为光给别人文件，受字典数据文件的影响，对方是无法使用的。

       6、如果和MyISAM比insert写操作的话，Innodb还达不到MyISAM的写性能，如果是针对基于索引的update操作，虽然MyISAM可能会逊色Innodb,但是那么高并发的写，从库能否追的上也是一个问题，还不如通过多实例分库分表架构来解决。

       7、如果是用MyISAM的话，merge引擎可以大大加快应用部门的开发速度，他们只要对这个merge表做一些select count(*)操作，非常适合大项目总量约几亿的rows某一类型(如日志，调查统计)的业务表。

       å½“然Innodb也不是绝对不用，用事务的项目如模拟炒股项目，我就是用Innodb的，活跃用户多万时候，也是很轻松应付了，因此我个人也是很喜欢Innodb的，只是如果从数据库平台应用出发，我还是会首选MyISAM。

       å¦å¤–，可能有人会说你MyISAM无法抗太多写操作，但是我可以通过架构来弥补，说个我现有用的数据库平台容量：主从数据总量在几百T以上，每天十多亿 pv的动态页面，还有几个大项目是通过数据接口方式调用未算进pv总数，(其中包括一个大项目因为初期memcached没部署,导致单台数据库每天处理 9千万的查询)。而我的整体数据库服务器平均负载都在0.5-1左右。

数据库｜一文教你解决on duplicate key update引发的索引数据不一致问题

       在数据库操作中，若遇到使用insert into... on duplicate key update时出现错误，这通常表示索引数据不一致。本文将深入分析此问题的原因、排查方法、问题解析、现象分析以及总结解决方案。

       首先，理解错误代码。在事务提交时，系统断言失败，原因是索引和数据存在不一致。根据TiDB的解释，当事务尝试提交时，发现一个在断言中假设不存在的key实际上已经存在，且是由特定事务写入。该key的Multi-Version Concurrency Control（MVCC）历史被记录在日志中。

       测试环境下的SQL执行结果显示，从第三条插入开始，即出现错误。初始疑惑在于为何少量数据插入便会导致索引不一致。观察发现，插入数据与索引数据在特定字段（如时间戳）存在差异，且差异指向自动更新时间戳（ON UPDATE CURRENT_TIMESTAMP）的设置。具体表现为，主键字段未随变更更新，而索引字段更新了最新时间戳，引发索引与主键数据不一致。

       问题根源在于自动更新时间戳导致的索引与主键数据不匹配。通过查阅GitHub上的相关issues，确认了这一现象的普遍性。现象一表现为在隐式事务提交下，自动更新操作导致索引更新但主键未更新，引发数据不一致。而现象二则是在显示事务提交下，批量插入最后未报错，检查时才出现错误提示。为解决此问题，可调整系统变量tidb_txn_assertion_level至最高级STRICT，以在提交阶段提示报错。值得注意的是，此变量在低版本集群原地升级时默认关闭，导致不报错，需手动调整至合适级别。

       总结而言，该问题源于自动更新字段导致索引与主键数据不匹配，尤其在自动更新设置下更为常见。解决方法包括在UPDATE语句中手动指定需要更新的字段，以及改用replace into方式代替insert into... on duplicate key update，以避免更新引发的数据不一致问题。通过这些措施，可有效防止索引数据不一致错误的出现。

面试突击：MVCC 和间隙锁有什么区别？

       MVCC（多版本并发控制）与间隙锁是数据库并发控制中的两种不同策略，它们的目的都是为了保证数据的一致性和并发访问。MVCC 是通过保存数据快照，每个读操作读取特定时间点的数据，避免读取未提交的数据，InnoDB 存储引擎就使用了这种方法。而间隙锁则锁定索引范围，防止其他事务在锁定范围内插入数据，确保数据的唯一性，InnoDB 中的 SELECT ... FOR UPDATE 语句即使用了间隙锁。

       尽管常规锁可以防止并发冲突，但 MVCC 的出现是因为它在性能上更具优势。MVCC 无需频繁加锁，而是通过版本控制实现并发，这使得在高并发场景下更为高效。MVCC 的实现依赖于 SQL 中的事务 ID和 Read View 中的版本号，通过对比决定使用快照还是历史数据。

       幻读是并发操作可能导致的问题，MVCC 能够通过读取固定版本的快照来解决部分幻读，但写操作时仍需配合其他机制。在 MySQL 的 InnoDB 中，RR（可重复读）事务隔离级别下，要完全避免幻读，通常需要结合 MVCC 和适当的锁机制，例如行锁、间隙锁等。

       MySQL 的锁机制包括行锁、间隙锁和临建锁，它们各自针对不同的并发场景。行锁锁定的是单个数据行，间隙锁锁定的是索引范围，而临建锁（临时表锁）用于锁定整个表。总结来说，MVCC 和这些锁机制共同维护了 InnoDB 存储引擎在高并发环境下的数据一致性。

       以上内容已收录于 Gitee 的开源项目《Java 面试突击》，涵盖了 Redis、JVM、并发、数据库、Spring 等技术，是全面的Java面试资源。持续更新，为你的面试准备提供支持。

mysql的两种存储引擎区别

       MySQL的两种常见存储引擎，InnoDB和MyISAM，在多个方面存在显著区别。

       InnoDB是MySQL的默认存储引擎，它支持事务处理、行级锁定和外键约束，这些特性使得InnoDB在需要高并发、事务完整性和数据一致性的应用场景中表现优异。InnoDB通过MVCC（多版本并发控制）来支持高并发，并且采用聚集索引的方式存储数据，这意味着表的数据和主键索引是绑定在一起的，这有助于提高主键索引的查询效率。然而，InnoDB不保存表的具体行数，因此在执行某些查询时可能需要进行全表扫描，影响性能。

       相比之下，MyISAM是MySQL早期的默认存储引擎，它不支持事务处理和外键约束，但支持全文索引和表锁定。MyISAM的索引和数据是分离的，索引文件仅保存记录所在页的指针，这种非聚集索引的方式使得MyISAM在读取操作较多的场景下表现良好。MyISAM还使用一个变量来保存整个表的行数，这使得执行如SELECT COUNT(*) FROM table的查询时速度非常快。然而，MyISAM的表级锁机制在并发写入时可能会导致性能瓶颈。

       综上所述，InnoDB和MyISAM各有优劣，选择哪种存储引擎取决于具体的应用场景和需求。对于需要事务支持、高并发和数据一致性的应用，InnoDB是更好的选择；而对于读取操作较多、写入操作较少且不需要事务支持的应用，MyISAM可能更为合适。

对于MVCC的理解

        MVCC，全称Multi-Version Concurrency Control，即多版本并发控制，为多个版本的数据实现并发控制的技术。其基本思想是为每一次事务生成一个新版本的数据，在读取数据时可以选择不同版本的数据即实现的事务结果的完整性读取。（基于Mysql的回滚机制为达到并发场景下的读操作不需要锁定）

        实现原理：主要是依赖记录中的三个隐式字段、undo日志、ReadView

        三个隐式字段：

        DB_TRX_ID

        6byte，最近修改(修改/插入)事务ID：记录创建这条记录/最后一次修改该记录的事务ID

        DB_ROLL_PTR

        7byte，回滚指针，指向这条记录的上一个版本（存储于rollback segment里）

        DB_ROW_ID

        6byte，隐含的自增ID（隐藏主键），如果数据表没有主键并且没有唯一键，InnoDB会自动以DB_ROW_ID产生一个聚簇索引

        下面看一下MVCC的整个的运作的流程

        一、 比如一个有个事务插入persion表插入了一条新记录，记录如下，name为Jerry, age为岁，隐式主键是1，事务ID和回滚指针，我们假设为NULL

        二、 现在来了一个事务1对该记录的name做出了修改，改为Tom

        从上面，我们就可以看出，不同事务或者相同事务的对同一记录的修改，会导致该记录的undo log成为一条记录版本线性表，既链表，undo log的链首就是最新的旧记录，链尾就是最早的旧记录。

        查询时会读出ReadView；[未提交的事务id]数组 + 最大事务id，并根据ReadView从undo log日志中最新记录依次往下找

        本篇文章参考 /p/ddca3b

        B站还有个程序猿up讲的这个也很不错 /video/BV1Vk4y1k7KQ?from=search&seid=

MySQL幻读：MVCC与间隙锁

       MySQL的幻读问题主要涉及MVCC（多版本并发控制）和间隙锁两种机制。在Read Committed和Read Repeatable隔离级别下，快照读通过MVCC来处理幻读，利用历史版本数据避免数据的不一致性。而当前读则通过间隙锁确保一致性，尤其是在RR（可重复读）级别，InnoDB默认的隔离级别，即使在不启用innodb_locks_unsafe_for_binlog的情况下，next-key locks（间隙锁）能防止索引扫描中的幻读现象，即保证事务在读取期间数据不会被其他事务插入或修改。

       如果需要实时数据，应用需要手动使用next-key locks，如在SELECT语句后加上lock in share mode，以获取最新的数据。然而，这会导致并发性能降低，因为涉及到加锁。MVCC的优势在于无锁并发，但不能保证实时数据，而next-key锁则提供实时数据但需要加锁。

       在RR级别下，虽然MVCC解决了重复读问题，但在某些场景下，它仍允许幻读，因为使用的是历史数据。而要完全避免幻读，通常需要将快照读升级为当前读，此时MySQL会使用next-key locks确保数据的完整性和一致性。

       总之，MySQL的幻读处理策略依赖于事务隔离级别和锁定机制的选择，理解并正确使用这些机制对于保证数据一致性至关重要。对于更深入的学习，建议查阅官方文档或相关技术资料。