① informix 逻辑日志与物理日志分配多大
1．物理日志
物理日志的作用在于保持一批dbspace页的前映象。这些“前映象”代表了所有数据在物理上与逻辑上都保持一致的这样一个时刻。将物理日志中的前映象与逻辑日志中的逻辑日志记录结合起来，可以恢复数据库自上一次已知的一致点以来发生的所有事务。这样的已知的一致点称为检查点。在快速恢复过程中，第一步首先用到物理日志，将整个系统恢复在Online中最近一次检查点时所处的物理一致的状态。
1） 物理日志的存放地址
当IDS初始化时，将会在rootdbs中创建物理日志。
当IDS处于静止方式时，用户可将物理日志从一个dbspace移到另一个dbspace中。用户这样做的目的是想尽量提高效率。
物理日志的位置由配置文件中的PHYSDBS参数指定。这个参数仅当用户决定将物理日志从 rootdbs中移到另一个dbspace中才必须被改变；否则，该参数在缺省情况下，仍包含着rootdbs的名称。
物理日志的大小由配置参数PHYSFILE指定，以kb为单位。用户可以修改物理日志文件的位置和大小。
2） 物理日志的内容
物理日志是一组连续的磁盘页面，每一个都包含有一个特别的Online页的副本。物理日志中的页面可以是除了blobspace中blobpage以外的其它任何Online页面。甚至可对应于系统开销页，例如chunk空闲链页、blobspace空闲映象页、blobspace位图页等等，这些页也必须在其上的数据被修改并刷新到磁盘上之前被复制到物理日志中去。
Blobspace blobpage并不出现在物理日志中，这是因为blob采用与其它数据类型不同方法记录日志。
3） 物理日志前映象
在某一次检查点后，某个页面第一次被修改时，该页的“前映象”将被写入共享内存中的物理日志缓冲区。在该被修改的页从共享内存刷新到磁盘上之前，该页的“前映象”应首先被刷新到磁盘上物理日志中。需要注意的是，仅当对页面的第一次修改才会导致往物理日志中写“前映象”。先写日志文件原则是为快速恢复所必需的。
4） 检查点操作逻辑地清空物理日志
每次Online检查点操作以后，物理日志中逐渐被填上发生修改的“前映象”。当再一次检查点操作发生以后的瞬间，这时Online中的数据在物理上是一致的，这时也就再不需要原来的Online物理日志中的“前映象”了。（这对于继续执行的事务也同样适用。如果某一个这样的事务需要执行回滚操作，则执行回滚所需的信息都已包含在逻辑日志文件中了。）在检查点操作完成时，Online将逻辑上清空逻辑日志，Online仅仅重置物理日志中的指针，标明下一组“前映象”所存储的起始位置。Online 循环使用物理日志，不断地覆盖那些已过时的数据。
检查点操作是唯一可以清空物理日志的机制。如果物理日志75%的空间已被占用，则Online将启动一次检查点操作。
2．逻辑日志
逻辑日志文件的作用在于自上一次Online archive以来，对Online数据所发生的变化进行记录。Online把逻辑日志分成三个或更多个相互分离的磁盘空间，每磁盘空间称为一个逻辑日志文件。相应于每一个逻辑日志文件有一个唯一标识号。
1） 逻辑日志与快速恢复
Online使用逻辑日志可以恢复自上一次已知的物理一致点以来发生的所有事务。这一已知的物理一致点在Online系统中称为检查点。快速恢复中，当Online使用物理日志将整个系统恢复到上一次检查点时所处的状态以后，Online将使用逻辑日志记录将整个系统恢复到最近一次逻辑日志记录时刻的逻辑一致性状态，这实际上是快速恢复的第二步骤。
2） 逻辑日志与数据恢复
将逻辑日志文件的备份磁带与最近一次的Online的archive结合在一起，可以将Online系统重新恢复到最近一次逻辑日志记录时的状态。
3） 逻辑日志文件被循环使用
Online通过标识一个逻辑日志文件为used（使用）状态来保护逻辑日志文件不被覆盖，直至该文件被备份到磁带上并且快速恢复已不再需要该逻辑日志文件时为止。当一个逻辑日志文件中的所有记录对应的事务都已完成时，快速恢复过程将不再需要该逻辑日志文件。如果上面所说的两个重要条件都已被满足，即逻辑日志文件已被备份到磁带上，并且快速恢复也已不再需要该逻辑日志文件，这时Online将该逻辑日志文件标记为free（空闲）状态，该文件也就可以被再次用以填如逻辑日志记录。
在 Online处理过程中，Online按数字顺序依次填充空闲的（即状态为free）的逻辑日志文件。当第一个逻辑日志文件变满时，Online接着开始填充下一个逻辑日志文件，如果下一次逻辑日志的状态为“used”而不是“free”，则正常的Online处理将被挂起。Online不能跳过该标记为“used”状态的逻辑日志文件而去填充别的空闲的日志文件。保证空闲的逻辑日志文件在Online处理过程中总可以被得到，这是Online管理员的职责。
Online至少需要三个逻辑日志文件以便循环使用逻辑日志文件，当一个逻辑日志文件在接收当前记录时，Online有可能正将另一个日志文件往磁带上备份，第三个日志文件是当前日志文件已满，而备份另一个日志文件的工作尚未完成时所需要的。（这个使用三个逻辑日志缓冲区的考虑是类似的）。
4） 逻辑日志文件：标识号与备份
逻辑日志备份带以逻辑日志所包含的唯一数值标记。每当一个日志文件填满时，逻辑日志标识号就增加数值1。例如，如果一个Online系统包含三个逻辑日志文件，则相应的三个日志文件的标识号为1、2、3。当逻辑日志文件1第一次被释放以便循环使用时，它将变为逻辑日志文件4，第二次它又将变为逻辑日志文件7。
5） 逻辑日志文件的内容
逻辑日志文件中包含下述五种类型的记录：
所有数据库的SQL定义语句。
检查点记录。
有关配置修改的记录。
对于那些创建时使用日志登录的数据库的SQL数据操纵语句。
有关某个数据库日志登录状态变化的记录。
即使没有一个数据库创建时使用了事务日志登录，在处理过程中，Online也会将前面三种类型的记录写入逻辑日志文件。逻辑日志记录可以跨越Online的整个页面，但它们却不能跨越逻辑日志文件。
6） 逻辑日志文件的配置
当Online初始化时将会在rootdbs中创建逻辑日志文件。在Online处于静止方式以后，用户可以从rootdbs中删除一个或多个逻辑日志文件，也可以往另一个dbspace中增加一个或多个逻辑日志文件。用户有可能为了提高效率而这样做。
在Online磁盘空间初始化以后，用户就不能再修改逻辑日志文件的大小了。如果一逻辑日志文件被删除，则由该逻辑日志文件占据的空间将被释放掉，并被链入chunk空闲链页。
7） 大小与数目方面的限制
Online管理员决定每一个逻辑日志文件的大小，以及分配给整个逻辑日志的磁盘空间的大小。每个逻辑日志文件至少要被分配到200K的磁盘空间。
逻辑日志文件的最小数目为3，最大数目则由一页上可容纳的逻辑日志描述字的数目所决定。对于一个2K大小的页，最大的日志文件数目为60。
8） 影响逻辑日志文件填充速度的因素
下列四个因素会影响一个事务的大小与持续时间：
逻辑日志文件记录的大小
事务打开时间的长度
CPU与逻辑日志的活动级别（Actirity Level）
事务回滚的频率（Freqency）
逻辑日志记录的长度随处理操作与当前Online的环境而变化。一般来讲，数据行越长，逻辑日志记录也就越大。
不仅如此，其它一些因素还会影响单一事务的大小与操作时间。例如，一条Alter table语句将会为每一次往新修改了的表中的插入操作生成一条逻辑日志记录。数据行的大小与表的大小都将会影响生成的逻辑日志记录的数目与大小。然而在一些情况下，数据行大小是无关紧要的。例如，逻辑日志中的一条检查点记录将包含对应于所有检查点发生时刻仍处于打开状态的事务的项目。检查点记录的大小仅仅反映了当前的数据库活动的级别与类型，而不涉及到任何特定的行的大小。
事务的持续时间也是一个不能为用户所控制的主要的变化量。一个应用，也许并不需要过多的逻辑日志记录空间，但如果用户允许事务在很长时间内保持打开，这时就可能造成生成长事务错误。在保证不产生长事务错误的前提下，可用的逻辑日志空间越多，就有可能允许越长的事务保持打开状态。
CPU的能力可能影响Online服务器进程完成事务的能力。重复地往逻辑日志文件写，增加了每个服务器进程完成事务所需的CPU时间。逻辑日志操作的增加，可能还隐含着同时增加了对逻辑日志锁与latch的竞争。（也正是这个原因，用户才有可能需要将逻辑日志文件从rootdbs移到另一个不太活跃的dbspace中去）。
回滚的频率也影响着逻辑日志被填充的速率。尽管回滚记录很小，但回滚本身也需要逻辑日志文件空间。而且，回滚也增加对逻辑日志的操作。
② 汗颜！工作10年去面试，被“MySQL怎么保证事物一致性”难倒了
阿牛去一家中意的公司面试，本以为凭借以往丰富的经验，肯定手到擒来，结果第一个问题，我就“出门右拐”了。
问题就是：MySQL是怎么保证事务一致性的？
回到家阿牛翻阅资料，终于搞懂了，在这里分享给大家。
定义
在搞清楚问题答案之前，先搞清楚以下几个名词以及大致的用处
redo log：
通常是物理日志，记录的是数据页的物理修改，而不是某一行或某几行修改成怎样怎样，它用来恢复提交后的物理数据页(恢复数据页，且只能恢复到最后一次提交的位置)、Innodb特有的，他在存储引擎层。循环写的，空间固定会用完。作用是crash-safe能力
binlog：
是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ” 是 MySQL 的 Server 层实现的，所有引擎都可以使用。是可以追加写入的,“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。作用是数据归档
undo log：
有两个作用：提供回滚和多个行版本控制(MVCC)。
在数据修改的时候，不仅记录了redo，还记录了相对应的undo，如果因为某些原因导致事务失败或回滚了，可以借助该undo进行回滚。
SQL执行的过程
了解了以上名词之后，让我们看一下“一条更新SQL语句执行的过程是什么？”
如图1有几个关键步骤：
1、先查找记录所在的Innodb页在不在内存里；如果不在内存里则将记录所在的页加载在内存里；根据SQL语句在内存中将记录更新
2、将更新前的记录写入undolog
3、根据记录的更新值将变更写入redolog（buffer）中，并将状态变更为prepare
4、将变更记录到逻辑日志
5、redolog日志中的状态修改为commit，返回结束
至此：一条更新语句的过程结束
上面的步骤中有些同学可能会有一些疑问：为什么更新一条记录要把一整页数据加载到内存里答：因为Innodb引擎中，最小的存储单位是页为什么一定要加载到内存里？答：因为所有的计算操作都是在内存里，操作完成后最终才写回磁盘为什么要写入redolog，直接写入磁盘，然后写入binlog就好了啊？答：这将在下面会提到，请往后看
为了加深理解，准备了下面2张图辅助理解
以图3为例，让我们看看在每个步骤出现异常的时候，到底怎么保证事物一致性的吧！1、步骤123，所有的操作最多还只是内存里，如果出现宕机、断电等异常， 记录不会有任何变动，事物是一致的2、步骤4刚执行完，断电了，因为redolog还处在prepare状态， 这时候事物也是一致的3、步骤5记录binlog的过程中断电了，这时候要保证主从一致性， 事物也是不生效的，最终也是一致的4、步骤6、7如果中间任何一个时刻断电了，这时候情况就不一样了，事物是生效的，因为redolog、binlog的数据都是完整的，服务器重启后可以按照xid来去查看binlog、redolog中是否都存在， 都存在该事物就是生效的。上面就是怎么保证事务一致性的根本原因
为什么要使用redolog？
回答这个问题之前，我们先看看redolog用图形表示的
图4是redolog的形象一点的表现，并不是说redolog 长这个样子，只是为了更形象；一般情况下redolog一组4个文件，每个文件1个G，其中write pos是指redolog当前写到什么位置了，check point是指上次刷脏结束的位置，当write log和check point重合时，所有的进程停止，开始新一轮的刷脏操作。刷完后redolog清空开始下一轮的写入，往返重复。
可能这样表示有点抽象，让我们看下图5
从上图中可以看的更形象一点，在sql执行的时候，会有磁盘IO将数据页加载到内存，然后在内存中将数据修改，修改后的数据页在内存中叫做脏页（叫脏页因为和磁盘中的数据不一致啊），又因为在内存中容易丢失，所以将数据页的变更记录如redolog中，随着记录插入、更新等操作的增多，redolog空间慢慢的满了，这时候就开始刷脏操作了，page cleaner thread线程会将所有的脏页数据刷新到磁盘，使得变更最终被持久化到磁盘。
讲到这里一定还会有人不太理解，刷脏之前断电了咋办？
这就是redolog的另一个重要的作用，crash-safe能力，实现的逻辑是这样的，断电后内存的数据都没了，重启后读取redolog文件，因为redolog文件记录的是在Innodb页x的m处做了y的修改，所以根据redolog将涉及到的Innodb页重新加载到内存，根据redolog的记录将内存中的数据重新修改，这样就能恢复断电前的数据了。
完
下期预告：还是MySQL，敬请期待
本文首发自： 程序员阿牛
③ 数据库的事务机制是什么
回答的有点多请耐心看完。
希望能帮助你还请及时采纳谢谢
1事务的原理
事务就是将一组SQL语句放在同一批次内去执行，如果一个SQL语句出错,则该批次内的所有SQL都将被取消执行。MySQL事务处理只支持InnoDB和BDB数据表类型。
1事务的ACID原则
** 1（Atomicity）原子性**： 事务是最小的执行单位，不允许分割。原子性确保动作要么全部完成，要么完全不起作用；
2（Consistency）一致性： 执行事务前后，数据保持一致；
3（Isolation）隔离性： 并发访问数据库时，一个事务不被其他事务所干扰。
4（Durability）持久性: 一个事务被提交之后。对数据库中数据的改变是持久的，即使数据库发生故障。
1缓冲池（Buffer Pool）
Buffer Pool中包含了磁盘中部分数据页的映射。当从数据库读取数据时，会先从Buffer Pool中读取数据，如果Buffer Pool中没有，则从磁盘读取后放入到Buffer Pool中。当向数据库写入数据时，会先写入到Buffer Pool中，Buffer Pool中更新的数据会定期刷新到磁盘中（此过程称为刷脏）。
2日志缓冲区（Log Buffer）
当在MySQL中对InnoDB表进行更改时，这些更改命令首先存储在InnoDB日志缓冲区（Log Buffer）的内存中，然后写入通常称为重做日志（redo logs）的InnoDB日志文件中。
3双写机制缓存（DoubleWrite Buffer）
Doublewrite Buffer是共享表空间的物理文件的 buffer,其大小是2MB.是一个一分为二的2MB空间。
刷脏操作开始之时,先进行脏页**‘备份’**操作.将脏页数据写入 Doublewrite Buffer.
将Doublewrite Buffer(顺序IO)写入磁盘文件中(共享表空间) 进行刷脏操作.
4回滚日志(Undo Log)
Undo Log记录的是逻辑日志.记录的是事务过程中每条数据的变化版本和情况.
在Innodb 磁盘架构中Undo Log 默认是共享表空间的物理文件的Buffer.
在事务异常中断,或者主动(Rollback)回滚的过程中 ,Innodb基于 Undo Log进行数据撤销回滚,保证数据回归至事务开始状态.
5重做日志(Redo Log)
Redo Log通常指的是物理日志，记录的是数据页的物理修改.并不记录行记录情况。（也就是只记录要做哪些修改，并不记录修改的完成情况） 当数据库宕机重启的时候，会将重做日志中的内容恢复到数据库中。
1原子性
Innodb事务的原子性保证,包含事务的提交机制和事务的回滚机制.在Innodb引擎中事务的回滚机制是依托 回滚日志(Undo Log) 进行回滚数据，保证数据回归至事务开始状态.
2那么不同的隔离级别，隔离性是如何实现的，为什么不同事物间能够互不干扰？ 答案是 锁 和 MVCC。
3持久性
基于事务的提交机制流程有可能出现三种场景.
1 数据刷脏正常.一切正常提交，Redo Log 循环记录.数据成功落盘.持久性得以保证
2数据刷脏的过程中出现的系统意外导致页断裂现象 (部分刷脏成功)，针对页断裂情况,采用Double write机制进行保证页断裂数据的恢复.
3数据未出现页断裂现象,也没有刷脏成功，MySQL通过Redo Log 进行数据的持久化即可
4一致性
从数据库层面，数据库通过原子性、隔离性、持久性来保证一致性
2事务的隔离级别
Mysql 默认采用的 REPEATABLE_READ隔离级别 Oracle 默认采用的 READ_COMMITTED隔离级别
脏读： 指一个事务读取了另外一个事务未提交的数据。
不可重复读： 在一个事务内读取表中的某一行数据，多次读取结果不同
虚读(幻读)： 是指在一个事务内读取到了别的事务插入的数据，导致前后读取不一致。
2基本语法
-- 使用set语句来改变自动提交模式
SET autocommit = 0; /*关闭*/
SET autocommit = 1; /*开启*/
-- 注意:
--- 1.MySQL中默认是自动提交
--- 2.使用事务时应先关闭自动提交
-- 开始一个事务,标记事务的起始点
START TRANSACTION
-- 提交一个事务给数据库
COMMIT
-- 将事务回滚,数据回到本次事务的初始状态
ROLLBACK
-- 还原MySQL数据库的自动提交
SET autocommit =1;
-- 保存点
SAVEPOINT 保存点名称 -- 设置一个事务保存点
ROLLBACK TO SAVEPOINT 保存点名称 -- 回滚到保存点
RELEASE SAVEPOINT 保存点名称 -- 删除保存点
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
/*
课堂测试题目
A在线买一款价格为500元商品,网上银行转账.
A的银行卡余额为2000,然后给商家B支付500.
商家B一开始的银行卡余额为10000
创建数据库shop和创建表account并插入2条数据
*/
CREATE DATABASE `shop`CHARACTER SET utf8 COLLATE utf8_general_ci;
USE `shop`;
CREATE TABLE `account` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`name` VARCHAR(32) NOT NULL,
`cash` DECIMAL(9,2) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=INNODB DEFAULT CHARSET=utf8
INSERT INTO account (`name`,`cash`)
VALUES('A',2000.00),('B',10000.00)
-- 转账实现
SET autocommit = 0; -- 关闭自动提交
START TRANSACTION; -- 开始一个事务,标记事务的起始点
UPDATE account SET cash=cash-500 WHERE `name`='A';
UPDATE account SET cash=cash+500 WHERE `name`='B';
COMMIT; -- 提交事务
# rollback;
SET autocommit = 1; -- 恢复自动提交
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
3事务实现方式-MVCC
1什么是MVCC
MVCC是mysql的的多版本并发控制即multi-Version Concurrency Controller，mysql的innodb引擎支持MVVC。MVCC是为了实现事务的隔离性，通过版本号，避免同一数据在不同事务间的竞争，你可以把它当成基于多版本号的一种乐观锁。当然，这种乐观锁只在事务级别为RR（可重复读）和RC（读提交）生效。MVCC最大的好处，相信也是耳熟能详：读不加锁，读写不冲突，极大的增加了系统的并发性能。
2MVCC的实现机制
InnoDB在每行数据都增加两个隐藏字段，一个记录创建的版本号，一个记录删除的版本号。
在多版本并发控制中，为了保证数据操作在多线程过程中，保证事务隔离的机制，降低锁竞争的压力，保证较高的并发量。在每开启一个事务时，会生成一个事务的版本号，被操作的数据会生成一条新的数据行（临时），但是在提交前对其他事务是不可见的；对于数据的更新（包括增删改）操作成功，会将这个版本号更新到数据的行中；事务提交成功，新的版本号也就更新到了此数据行中。这样保证了每个事务操作的数据，都是互不影响的，也不存在锁的问题。
3MVCC下的CRUD
SELECT：
当隔离级别是REPEATABLE READ时select操作，InnoDB每行数据来保证它符合两个条件：
** 1 事务的版本号 大于等于 创建行版本号**
** 2 行数据的删除版本 未定义 或者大于 事务版本号**
【行创建版本号 事务版本号 行删除版本号】
INSERT：
InnoDB为这个新行 记录 当前的系统版本号。
DELETE：
InnoDB将当前的系统版本号 设置为 这一行的删除版本号。
UPDATE：
InnoDB会写一个这行数据的新拷贝，这个拷贝的版本为 当前的系统版本号。它同时也会将这个版本号 写到 旧行的删除版本里。
————————————————
版权声明：本文为CSDN博主“@Autowire”的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/zs18753479279/article/details/113933252