什么叫执行机制？

Posted 2023-03-23

执行(Speculative Execution)机制是指在分布式集群环境下，因为程序BUG，负载不均衡或者资源分布不均等原因，造成同一个job的多个task运行速度不一致，有的task运行速度明显慢于其他task（比如：一个job的某个task进度只有10%，而其他所有task已经运行完毕），则这些task拖慢了作业的整体执行进度，为了避免这种情况发生，Hadoop会为该task启动备份任务，让该speculative task与原始task同时处理一份数据，哪个先运行完，则将谁的结果作为最终结果。
执行优化机制采用了典型的以空间换时间的优化策略，它同时启动多个相同task（备份任务）处理相同的数据块，哪个完成的早，则采用哪个task的结果，这样可防止拖后腿Task任务出现，进而提高作业计算速度，但是，这样却会占用更多的资源，在集群资源紧缺的情况下，设计合理的推测执行机制可在多用少量资源情况下，减少大作业的计算时间。 参考技术A 你问的是什么执行机制？？

应用程序执行机制

3.4.1 WinMain函数

在DOS下，程序的执行是从main函数开始的。在Windows下，对应的函数是WinMain。但是，如果浏览Hello程序的所有的方法和全局函数，是找不到WinMain函数的。MFC考虑到典型的Windows程序需要的大部分初始化工作都是标准化的，因此把WinMain函数隐藏在应用程序的框架中，编译时会自动将该函数链接到可执行文件中。程序员可以重写WinMain函数，但一般不需要这么做。
下面的程序清单3-1给出了WinMain函数的代码。其中，_tWinMain函数在\DevStudio\Vc\Mfc\src\AppModul.cpp中定义，它所调用的AfxWinMain函数在同一目录下的WinMain.cpp中定义。名字是_tWinMain函数而不是WinMain，是考虑到对不同字符集的支持，在tchar.h中有_tWinMain的宏定义。在ANSI字符集下编译时，_tWinMain就变成WinMain，在Unicode下编译时，_tWinMain就变成wWinMain。

提示：Unicode是具有固定宽度、统一的文本和字符的编码标准。由于Unicode采用的是16位编码，因此可以包含世界各地的书写系统的字符和技术符号（如中文也在Unicode之中），从而克服了ASCII码在表示多语言文本上的不足之处，扩大了ASCII码7位编码方案的好处。Unicode同等地对待所有的字符，并且在表示各种语言的任何字符时既不需要换码序列（escape）也不需要控制代码。Win32和Visual C++很好的支持Unicode字符集。

清单3-1 _tWinMain函数定义

// export WinMain to force linkage to this module

extern int AFXAPI AfxWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,

LPTSTR lpCmdLine, int nCmdShow);

#ifdef _MAC

extern "C" int PASCAL

#else

extern "C" int WINAPI

#endif

_tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,

LPTSTR lpCmdLine, int nCmdShow)



// call shared/exported WinMain

return AfxWinMain(hInstance, hPrevInstance, lpCmdLine, nCmdShow);



AfxWinMain函数定义：

/////////////////////////////////////////////////////////////////////////////

// Standard WinMain implementation

// Can be replaced as long as 'AfxWinInit' is called first

int AFXAPI AfxWinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,

LPTSTR lpCmdLine, int nCmdShow)



ASSERT(hPrevInstance == NULL);

int nReturnCode = -1;

CWinApp* pApp = AfxGetApp();

// AFX internal initialization

if (!AfxWinInit(hInstance, hPrevInstance, lpCmdLine, nCmdShow))

goto InitFailure;

// App global initializations (rare)

ASSERT_VALID(pApp);

if (!pApp->InitApplication())

goto InitFailure;

ASSERT_VALID(pApp);

// Perform specific initializations

if (!pApp->InitInstance())



if (pApp->m_pMainWnd != NULL)



TRACE0("Warning: Destroying non-NULL m_pMainWnd\n");

pApp->m_pMainWnd->DestroyWindow();



nReturnCode = pApp->ExitInstance();

goto InitFailure;



ASSERT_VALID(pApp);

nReturnCode = pApp->Run();

ASSERT_VALID(pApp);

InitFailure:

#ifdef _DEBUG

// Check for missing AfxLockTempMap calls

if (AfxGetModuleThreadState()->m_nTempMapLock != 0)



TRACE1("Warning: Temp map lock count non-zero (%ld).\n",

AfxGetModuleThreadState()->m_nTempMapLock);



AfxLockTempMaps();

AfxUnlockTempMaps(-1);

#endif

AfxWinTerm();

return nReturnCode;



应用程序执行时，Windows自动调用应用程序框架内部的WinMain函数。如清单3-1所示，WinMain函数会查找该应用程序的一个全局构造对象，这个对象是由CWinApp派生类构造的，有且只有一个。它是一个全局对象，因此在程序启动时，它就已经被构造好了。
随后，WinMain将调用这个对象的InitApplication和InitInstance成员函数，完成应用程序实例的初
始化工作。随后，WinMain调用Run成员函数，运行应用程序的消息循环。在程序结束时，WinMain调用AfxWinTerm函数，做一些清理工作。

3.4.2 应用程序类

每个应用程序必须从CWinApp派生出自己的应用程序类，并定义一个全局的对象。该应用程序类包含了Windows下应用程序的初始化、运行和结束过程。基于框架建立的应用程序必须有一个（且只能有一个）从CWinApp派生的类的对象。在Hello程序中，我们从CWinApp中派生出一个CHelloApp类，并定义了一个全局对象theApp。CHelloApp类在hello.cpp中定义。
要访问应用程序类构造的对象，可以调用全局函数AfxGetApp()。AfxGetApp()返回一个指向全局对象的指针。可以通过对它进行强制类型转换，转换为我们派生的应用程序类。

比如：

CHelloApp* pApp=(CHelloApp*)AfxGetApp()；

在CHelloApp应用程序类中，我们还重载了CWinApp的成员函数InitInstance。InitInstance函数主要完成以下工作：设置注册数据库，载入标准设置（最近打开文件列表等）、注册文档模板。其中注册文档模板过程中隐含地创建了主窗口。接着，处理命令行参数，显示窗口，然后返回、进入消息循环。下面的程序清单3.2给出了Hello程序的InitInstance函数代码。

清单3.2 InitInstance函数

// CHelloApp initialization

BOOL CHelloApp::InitInstance()



AfxEnableControlContainer();

// Standard initialization

// If you are not using these features and wish to reduce the size

// of your final executable, you should remove from the following

// the specific initialization routines you do not need.

#ifdef _AFXDLL

Enable3dControls(); // Call this when using MFC in a shared DLL

#else

Enable3dControlsStatic(); // Call this when linking to MFC statically

#endif

// Change the registry key under which our settings are stored.

// You should modify this string to be something appropriate

// such as the name of your company or organization.

SetRegistryKey(_T("Local AppWizard-Generated Applications"));

LoadStdProfileSettings(); // Load standard INI file options (including MRU)

// Register the application's document templates. Document templates

// serve as the connection between documents, frame windows and views.

CSingleDocTemplate* pDocTemplate;

pDocTemplate = new CSingleDocTemplate(

IDR_MAINFRAME,

RUNTIME_CLASS(CHelloDoc),

RUNTIME_CLASS(CMainFrame), // main SDI frame window

RUNTIME_CLASS(CHelloView));

AddDocTemplate(pDocTemplate);

// Parse command line for standard shell commands, DDE, file open

CCommandLineInfo cmdInfo;

ParseCommandLine(cmdInfo);

// Dispatch commands specified on the command line

if (!ProcessShellCommand(cmdInfo))

return FALSE;

// The one and only window has been initialized, so show and update it.

m_pMainWnd->ShowWindow(SW_SHOW);

m_pMainWnd->UpdateWindow();

return TRUE;



在CWinApp的派生类中，必须重载InitInstance函数，因为CWinApp并不知道应用程序需要什么样的窗口，它可以多文档窗口、单文档窗口，也可以是基于对话框的。

Run成员函数
WinMain在初始化应用程序实例后，就调用Run函数来处理消息循环。Run成员函数不断执行消息循环，检查消息队列中有没有消息。如果有消息，Run将其派遣，交由框架去处理，然后返回继续消息循环。如果没有消息，Run将调用OnIdle来做用户或框架可能需要在空闲时才做的工作，象后面我们讲到的用户接口更新消息处理等。如果既没有消息要处理，也没有空闲时的处理工作要做，则应用程序将一直等待，直到有事件发生。当应用程序结束时，Run将调用ExitInstance。消息循环的流程图如图3-10所示。

图3-10 Run成员函数的消息循环

关闭应用程序

用户可以通过选择File-Exit菜单或点主窗口的关闭按钮，关闭主框架窗口，来终止应用程序。此时，应用程序类首先删除m_pMainWnd主框架窗口对象，然后退出Run函数，进而退出WinMain，在退出WinMain后删除TheApp对象。

参考资料：http://www.vckbase.com/study/article/vc_chap/chap3_4.htm

本回答被提问者采纳

Mysql事务随笔

一、什么是事务

　　数据库中的概念,按我个人理解:能够保证一组任务全部执行成功或者全部执行失败的这么个机制,叫事务

　　事务是数据库中重要概念,如果没有这种保障机制,数据库中的数据就是不安全的(就是无法保证数据的正确性)

　　在数据库中,一组任务,就是放在一起执行的多条sql

二、ACID保证数据安全

　　所以如何才能保证数据安全呢?前人总结了如下四点

　　1.原子性,一组任务全部执行成功或者全部执行失败.这是基础,因为我们一组操作一般是有顺序的,有互相依赖关系的,要同步的,不能A表修改了,B表修改失败,这样数据就不同步了,也就是不正确了

　　2.一致性,就是我们的一组操作应该合辙(合乎逻辑,合乎道理),常见例子就是互相转账的例子:A转给C  10块,B转给C  20块  ,C最后手里一定要多  30块,这样就是保证了一致性,这样数据才正确

　　3.隔离性,隔离性在并发事务中才能体现作用,每个单独的事务要保证数据正确性,那么同时并发的多个单独的事务最后的结果,也应该保证最后数据正确

　　4.持久性,就是我们所做的操作必须被持久的保存下来,不能说事务正确的结束了,但是数据库没有被修改,这时数据也是不正确的.

　　所以保证数据正确性,就要保证数据开始是正确的,过程中每一步操作都是正确的(原子性,隔离性),最后结果是正确的(一致性),而且结果被正确的保留下来(持久性)

　　我们给这些特性总结了一个名字,叫事务,所以很多不理解事务的童鞋,可以不要去理解事务是什么,而应该反过来理解什么是事务(长成这样的就是事务)

要保证事务,需要理解的知识点如下:

　　两do一点:redo日志,undo日志,checkpoint

　　MVCC(ReadView)

　　事务隔离级别

　　savepoint

　　锁

　　MDL锁

　　这里我只是给自己留的随笔,所以不会详细讲解,但是会留入口

三、事务流程

大致分这么三条线

　　第一条红线:成功结果,事务正常执行,开启事务直到提交事务,刷新到硬盘上(只有进入硬盘才算持久化完毕,但并不是说数据要刷入硬盘,而是redo日志进入硬盘,即可保证持久性)

　　第二条橘线和第三条绿线:都是失败结果,原因可以是报异常,或者手动回滚数据,导致事务失败,完成回滚(使用undo日志回滚数据)

　　只有当事务处于提交的或者中止的状态时，一个事务的生命周期才算是结束了。对于已经提交的事务来说，该事务对数据库所做的修改将永久生效(redo日志的作用)，对于处于中止状态的事务，该事务对数据库所做的所有修改都会被回滚到没执行该事务之前的状态(undo日志的作用)。

 

四、事务的开启与提交与回滚操作

　　前提: 数据库默认事务自动提交,所以默认每一条sql的执行都是一个单独的事务

 

　　　　  涉及到的系统参数为autocommit ,ON和OFF

　　　　  查看    show variables like ‘autocommit‘ 

　　　　  修改    SET autocommit = OFF;  -- 关闭自动提交事务

　　　　  一般的,如果需要向数据库导入大量数据,由于sql执行默认单条sql为一次事务,如果有10条sql,就会分别开启事务提交事务10次,所以可以先关闭事务自动提交,自己手动开一次,执行sql,提交事务

 

 

　　1.开启事务:两种命令

　　　　BEGIN [WORK]   (BEGIN  等价于  BEGIN WORK , 所以work可以写可以不写)

　　　　START TRANSACTION [READ ONLY | READ WRITE | WITH CONSISTENT SNAPSHOT];

　　　　两种语法区别:第二种可以指定事务是只读模式(事务中不能有写操作的sql),读写模式(事务中可读可写,默认的)和一致性读(一致性读,又称为快照读。使用的是MVCC机制读取undo中的已经提交的数据。所以它的读取是非阻塞的)

　　　　一致性读参看 https://www.cnblogs.com/digdeep/p/4947694.html

 　　　　如果我们不显式指定事务的访问模式，那么该事务的访问模式就是读写模式

　　2.提交事务:一种命令

 　　　　COMMIT [WORK]     (COMMIT 等价于  COMMIT WORK , 所以work可以写可以不写)

　　3.回滚事务:一种命令

　　　　ROLLBACK [WORK]   (ROLLBACK 等价于  ROLLBACK WORK , 所以work可以写可以不写)

　　4.回滚到savepoint

　　　　SAVEPOINT [自定义savepoint的name];   -- 设置保存点

　　　　ROLLBACK TO [自定义savepoint的name]   -- 回滚到之前的某个保存点(只能在当前状态向前回滚,不能向后回滚)

上面说的是手动提交事务,mysql中还有一些自动会提交事务的命令

　　手动提交事务使用commit,但是有些语句会自动提交当前事务,称之为隐式提交

　　1.头一个就是开启自动提交事务,当前sql的事务会隐式提交

 　　2.DDL会隐式提交事务

1. 1. 如果A事务对T表有DML事务,未提交之前A事务执行了对T表表结构的修改,会自动提交A事务,然后执行DDL.
   2. 如果A事务对T表有DML事务,B事务修改非A表表结构,会将B事务自动提交,但不会影响到A事务,A事务依然没有提交,程序正常运行,新起一个C事务依然读不到A事务未提交的数据
   3. 如果A事务对T表有DML事务,B事务修改T表表结构,由于修改同一张表,按道理是要有锁保护的,否则A事务改字段B事务改表结构不就冲突了么,但mysql5.1之前确实是没有所以B事务可以直接执行DDL操作，并且导致A事务出错,但是在mysql5.5之后引入了一个MDL锁,这样就会让事务按顺序执行,我的mysql版本为8.0,所以我看到的效果是B事务的DDL一直等待(因为先开始A事务,而且A事务并未提交).直到A事务提交后,B事务的DDL才会执行.这个操作基于MDL锁(参看  http://www.cnblogs.com/zengkefu/p/5690385.html)
      
      结论:DDL只会隐式提交自己当前的事务,不会操作其他事务,如果冲突,则等待,基于MDL锁(如果影响到了其他事务(其它事务中有当前DDL的表),会等待直到其他事务提交后才能执行DDL操作.)

 　　　　　　   最后一句话:不要在程序运行过程中随便DDL,因为如果DDL会锁全表,如果表中数据量大,就会卡住别的事务,影响生产环境

　　　　　　　　但如果在生产环境中修改表结构怎么办

　　　　　　　　这里留两个博客,我自己没尝试过,之后再深研究

 　　　　　　　　http://www.cnblogs.com/wangtao_20/p/3504395.html(灵感来源)

 　　　　　　　　https://zhang.ge/5134.html (版本较新)  在线ddl工具(直接甩锅运维了[手动偷笑])(这个博客个人感觉很详细,所以自己留了一份截图,以防之后404 

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　(传送门: https://www.cnblogs.com/fast-bullet/p/10848561.html)

　　3.BEGIN命令    

　　　　开始事务的操作会隐式提交当前所在事务,然后另开一个事务

　　4.使用LOCK TABLES、UNLOCK TABLES等关于锁定的语句也会隐式的提交前边语句所属的事务

　　5.比如我们使用LOAD DATA语句来批量往数据库中导入数据时，也会隐式的提交前边语句所属的事务。

　　6.关于MySQL复制的一些语句

 　　　　使用START SLAVE、STOP SLAVE、RESET SLAVE、CHANGE MASTER TO等语句时也会隐式的提交前边语句所属的事务。

 　　　　使用ANALYZE TABLE、CACHE INDEX、CHECK TABLE、FLUSH、 LOAD INDEX INTO CACHE、OPTIMIZE TABLE、REPAIR TABLE、RESET等语句也会隐式的提交前边语句所属的事务。

 五、redo日志

　　为了将数据持久的保存下来,同时没保存之前还不能更改数据库,所以我们需要将我们所做的所有操作笔记一下,之后需要还原数据(这里的还原不等于回滚,应该是还原到他原本的样子,即操作完的样子),我们只需要按照笔记一步一步操作就行了.这个笔记就是redo日志(重做日志)

　　redo日志:重做日志,事务中包括多条sql,一条sql可能会对数据库的基础结构(如:B+树,数据页,索引,隐藏列等)产生操作,我们称之为MTR(mini transaction),每个MTR都会记录成一条至多条redo日志,mtr相当于底层最小的一次原子性操作,所以我们redo日志一般是多条才能表示一次原子操作

　　这样的话,多条redo日志组成一个MTR,多个MTR组成一条sql,多条sql组成一次事务,只要redo日志存在,就能将当前事务永久的保存下来(持久性)

　　redo日志会按顺序纪录当前事务操作,保证数据持久化,如果一个事务中只有一条操作,就只记录一条redo日志,如果一个事务有多条操作,就会纪录多条日志,我们上面说了,可能多条日志才是一个原子性操作,但是程序怎么知道日志是从哪到哪算是一组呢?mysql中每条redo日志占用8个字节,其中7个字节用来存储日志内容,最左边的第八个位置用来做标记,如果是单条日志则为1,如果是多条日志则为0,这样扫描到1说明当前为一个原子操作,数据恢复即可,如果是多条,会在所有操作记录完之后再加一个类型为MLOG_MULTI_REC_END类型的redo日志,扫描到这个日志,就知道当前操作完成,才会恢复之前一组redo日志,否则直接丢弃,保证未提交数据不被恢复.

 　　现在我们了解了redo日志的作用,mysql的持久化依赖于redo日志,redo日志是否被记录到硬盘中是持久化实现的关键,我们知道刷盘操作很慢,所以我们的redo日志一开始会记录在一个叫log buffer的缓冲区中,那么什么时候会将缓冲中的日志刷到磁盘呢?

　　1.当内存不足

　　2.事务提交时会刷到硬盘中(这样就能保证持久化,mysql中提供了设置,也可以设置事务提交时不持久化)

　　3.mysql后台有一个线程，大约每秒都会刷新一次log buffer中的redo日志到磁盘保证数据持久化　　

　　这个redo日志会被存放在mysql的data下的ib_logfile[数字]文件下

 

 六、undo日志

　　但是我们有时候可能需要回滚操作,比如事务中间出错,或者手动rollback,这个时候我们不能用redo日志来操作,否则我们一条一条redo要执行到哪年才算完啊,于是有了undo日志,这个日志用来备份,比如你把张三改成李四,undo日志会先将张三保存下来,然后再改成李四,这样你想要回滚的时候,我一下就知道李四之前是张三,因为我做了备份,直接还原即可,(可以说备份,也可以理解成当前数据快照,或者说会记录一条如果你要回滚,需要做什么样的操作)

　　你插入一条记录时，至少要把这条记录的主键值记下来，之后回滚的时候只需要把这个主键值对应的记录删掉就好了。

　　你删除了一条记录，至少要把这条记录中的内容都记下来，这样之后回滚时再把由这些内容组成的记录插入到表中就好了。

　　你修改了一条记录，至少要把修改这条记录前的旧值都记录下来，这样之后回滚时再把这条记录更新为旧值就好了。

这样事务一旦出问题,之间按照undo回滚即可

　　一般的,所有写库操作都会放在事务中执行,每个事务又有自己的一个id,undo日志会按顺序记录数据内容和事务id,方便日后回滚,因为不能因为A事务回滚而把B事务已提交的操作撤销,互相不能有影响(隔离性)

七、事务隔离性

　　多个事务在并发时,可能产生如下问题

　　1.脏写(丢失更新)

　　所谓脏写,就是A事务修改了一条数据还未提交,B事务也去修改这个数据,然后A事务提交了,发现不是自己想要的结果,自己改的数据没了,这就是丢失更新.

　　这个问题不需要考虑,因为不管数据库哪个隔离级别，当两个事务A和B尝试去更新同一条数据时，假定A先更新数据，会对更新的数据行记录加上排他锁(也叫写锁，悲观锁)，除非事务A提交或终止从而释放排他锁，否则事务B都是无法更新数据的。加锁排队修改.避免脏写

 　　2.脏读

　　所谓脏读，就是指事务A读到了事务B还没有提交的数据，比如数据库中有个数据100，事务A开启事务，此时切换到事务B，事务B开启事务将100-1,还未提交，此时切换回事务A，事务A读取到了99，因为事务B还未提交，就让A读到了,我们说A事务发生了脏读.为什么这是个问题呢,因为事务是可以回滚的,万一B回滚了事务,那么A读到的99其实是不存在的,就可能会出现问题

　　3.不可重复读(虚读)

　　所谓不可重复读，就是指在一个事务里面读取了两次某个数据，读出来的数据不一致。以银行取钱为例，事务A开启事务-->查出银行卡余额为1000元，此时切换到事务B事务B开启事务-->事务B取走100元-->提交，数据库里面余额变为900元，此时切换回事务A，事务A再查一次查出账户余额为900元，这样对事务A而言，在同一个事务内两次读取账户余额数据不一致，这就是不可重复读。

　　4.幻读

　　所谓幻读，就是指在一个事务两次查询的操作中发现了多了或者少了数据。比如学生信息，事务A查询所有大于20岁的学生信息，此时切换到事务B，事务B开启事务-->事务B插入了一条学生数据,年龄25，此时切换回事务A，事务A再次查询的时候发现多了一条数据，这就是幻读，幻读出现的前提是并发的事务中有事务发生了插入、删除操作。

　　正是因为多线程的原因，当某一个正在写数据时，另一个线程读取的数据是不准确的，所以需要进行同步处理.

　　mysql利用锁和MVCC(多版本并发控制)来解决上面所说的问题,为了方便设置,数据库规定了如下四个隔离级别,不同的隔离级别解决不同的问题

　　

这个图是随便找了一张,链接 https://www.erlo.vip/share/2/26041.html

 

　　一般生产中不太在意幻读的问题,所以生产环境一般设置隔离级别为不可重复读(RC),oracle默认就是RC,mysql默认级别为RR

　　那么mysql如何解决这些问题的呢,方案如下

八、MVCC的基础

　　MVCC  多版本并发控制.  

　　不解决任何问题隔离级别就是RU,不解决问题所以不考虑,之后RC和RR都是对于读的并发优化,解决并发读的问题主要依靠MVCC机制和锁

　　其中因为锁机制是一种预防性的，读会阻塞写，写也会阻塞读，当锁定粒度较大，时间较长是并发性能就不会太好；而MVCC是一种后验性的，读不阻塞写，写也不阻塞读，等到提交的时候才检验是否有冲突，由于没有锁，所以读写不会相互阻塞，从而大大提升了并发性能。

　　所以MVCC性能更加优秀,MySQL在 read committed ，Repeatable Read 两个级别下都会使用到MVCC, 并且只在这两个级别下使用。

　　MVCC利用readview和undo日志来实现

undo

　　这个MVCC和undo日志有什么关系呢,为啥要用undo实现?因为undo日志为了方便回滚,会按顺序记录数据内容和事务id,这样我之前的状态其实都在undo中,A事务操作数据会给undo加一条日志,B事务操作也会给undo加一条日志,对于数据库本身来说,现在是什么状态数据库自己是明明白白的,但是由于A事务没有提交,所以B事务在读数据的时候,应该读取A事务提交之前的样式,比如A将张三改成李四,这时候B读数据的时候,应该读到张三,因为李四还未持久化,那么这个张三在哪记录着呢,就在undo日志上,所以想要读事务之前的数据,就得靠undo日志.对同一条数据所做的多次操作会产生多条undo日志,而这些undo日志串起来的链条我们成为版本链(这个链表头就是当前的数据,不是说只记录历史,还包括当前数据),你的事务只能读到之前版本的数据,未提交的数据就读不到了,这样就保证了重复读

readview

　　对于使用RU隔离级别的事务来说，由于可以读到未提交事务修改过的记录，所以直接读取记录的最新版本就好了；对于使用SERIALIZABLE隔离级别的事务来说，设计InnoDB的大叔规定使用加锁的方式来访问记录,所以也跟MVCC没关系；对于使用READ COMMITTED和REPEATABLE READ隔离级别的事务来说，都必须保证读到已经提交了的事务修改过的记录，也就是说假如另一个事务已经修改了记录但是尚未提交，是不能直接读取最新版本的记录的，核心问题就是：需要判断一下版本链中的哪个版本是当前事务可见的。为此提出了一个ReadView的概念.

　　readview其实就类似与一个查询快照

　　1.如果使用READ COMMITTED隔离级别的事务,在每次查询开始时都会生成一个独立的ReadView。假如A事务开启->A事务查询(此时有一个快照)  ,  B事务开启->B事务修改内容(记录在了undo日志中) ->B事务提交, A事务继续第二次查询(由于又生出一个readview,所以这个readview长得和刚才那个不一样,是很正常的,这个readview能读到最新的数据,是因为B事务已经提交,A是可以直接读取undo日志上的新数据的)

　　2.如果使用REPEATABLE READ ,会在第一次读取数据时生成一个ReadView,之后每次查询都复用这个快照.假如A事务开启->A事务查询(此时有一个快照)  ,  B事务开启->B事务修改内容(记录在了undo日志中) ->B事务提交, A事务继续第二次查询(查询刚才那个快照)

 　　从上边的描述中我们可以看出来，所谓的MVCC（Multi-Version Concurrency Control ，多版本并发控制）指的就是在使用READ COMMITTD、REPEATABLE READ这两种隔离级别的事务在执行普通的SEELCT操作时访问记录的版本链的过程，这样子可以使不同事务的读-写、写-读操作并发执行，从而提升系统性能。READ COMMITTD、REPEATABLE READ这两个隔离级别的一个很大不同就是：生成ReadView的时机不同，READ COMMITTD在每一次进行普通SELECT操作前都会生成一个ReadView，而REPEATABLE READ只在第一次进行普通SELECT操作前生成一个ReadView，之后的查询操作都重复使用这个ReadView就好了。

 　　这样就保证了不可重复读的问题

 小结

　　MVCC读不影响写,写不影响读,实现高效率的可重复读(参考链接 https://www.imooc.com/article/17289)

　　1.读不影响写：事务以排他锁的形式修改原始数据，读时不加锁，因为 MySQL 在事务隔离级别Read committed 、Repeatable Read下，InnoDB 存储引擎采用非锁定性一致读－－即读取不占用和等待表上的锁。即采用的是MVCC中一致性非锁定读模式。因读时不加锁，所以不会阻塞其他事物在相同记录上加 X锁来更改这行记录。
　　2.写不影响读：事务以排他锁的形式修改原始数据，当读取的行正在执行 delete 或者 update 操作，这时读取操作不会因此去等待行上锁的释放。相反地，InnoDB 存储引擎会去读取行的一个快照数据(readview)。

 

 purge工作线程

　　题外话,正式由于有MVCC这种机制,所以删除操作执行的时候(还未提交事务),是不会删除掉数据的,而是打一个删除标记,这样MVCC才有机会读取到之前的readview,那什么时候真正删除这个数据呢?就需要用到purge工作线程了.类似于一个垃圾回收器.

 

网上很多帖子说防止幻读是使用了锁和MVCC,但是还有一部分人说MVCC不能防止幻读,这里给出一个订阅号文章,可以自己去看,关键点我复制到我这了

　　https://mp.weixin.qq.com/s/wSlNZcQkax-2KZCNEHOYLA 

　　MVCC不能禁止幻读的原理

　　T1第一次执行普通的SELECT语句时生成了一个ReadView，之后T2向hero表中新插入了一条记录便提交了，ReadView并不能阻止T1执行UPDATE或者DELETE语句来对改动这个新插入的记录（因为T2已经提交，改动该记录并不会造成阻塞），但是这样一来这条新记录的trx_id隐藏列就变成了T1的事务id，之后T1中再使用普通的SELECT语句去查询这条记录时就可以看到这条记录了，也就把这条记录返回给客户端了。因为这个特殊现象的存在，你也可以认为InnoDB中的MVCC并不能完完全全的禁止幻读。

九、锁

 

十、写在后面

　　参考文章 : 掘金小册中的<<MySql是怎样运行的:从根上理解MySql> >

　　作者 文章写的还是很详实的,通过阅读他的这本小册,写了上边的这篇随笔,这本小册读完让我对mysql中的一些原理又略知了三四,但是本人对于小册中很多细节还未能吸收,所以上面的文字描述并不是类似于教学一样教读者怎么做,权当自己的一篇随笔,记录一些关键知识点,简单串联了一下,如果有缘能看到这篇文章,建议可以去我提供的链接或者自己搜索其中知识点,已获得更加清晰的了解.

　　这篇文章能起到抛砖引玉的作用,足矣