1. MySQL一棵B+树能存多少条数据？
2. 如果MySql 引起 CPU 消耗过大，怎么优化
3. MySql 死锁问题如何解决
4. MySql 数据存储在磁盘上是什么样子
5. 数据库连接池到底应该设多大
6. 为什么delete 表数据，磁盘空间却还是被占用
7. 主从复制解决了什么问题，出现同步延迟如何解决

MySQL一棵B+树能存多少条数据？

1 数据持久化存储磁盘里，磁盘的最小单元是扇区，一个扇区的大小是512 字节
2 文件系统最小单元是 块，一个块的大小是4K
3 InnoDB 存储引擎，有自己的最小单元，称之为页，一个页的大小是 16K

MySQL 的最小存储单元叫做“页”，这么多的页是如何构建一个庞大的数据组织，我们又如何知道数据存储在哪一个页中？
如果逐条遍历，性能肯定很差。为了提升查找速度，我们引入了 B+ 树，先来看下 B+ 树的存储结构：
页除了可以存放数据（叶子节点），还可以存放健值和指针（非叶子节点），当然他们是有序的。这样的数据组织形式，我们称为索引组织表。

如：上图中 page number=3 的页，该页存放键值和指向数据页的指针，这样的页由 N 个键值+指针组成。

B+ 树是如何检索记录？
1 首先找到根页，你怎么知道一张表的根页在哪呢？
2 其实每张表的根页位置在表空间文件中是固定的，即 page number=3 的页。
3 找到根页后通过二分查找法，定位到 id=5 的数据应该在指针 P5 指向的页中。
4 然后再去 page number=5 的页中查找，同样通过二分查询法即可找到 id=5 的记录。

1 查询数据库时，不论读一行，还是读多行，都是将这些行所在的整页数据加载，然后在内存中匹配过滤出最终结果。
2 表的检索速度跟树的深度有直接关系，毕竟一次页加载就是一次 IO，而磁盘 IO 又是比较费时间。对于一张千万级条数 B+ 树高度为 3 的表与几十万级 B+ 树高度也为 3 的表，其实查询效率相差不大。

一棵树可以存放多少行数据？

假设 B+ 树的深度为 2，这棵 B+ 树的存储总记录数 = 根节点指针数 * 单个叶子节点记录条数。

那么指针数如何计算？假设主键 ID 为 bigint 类型，长度为 8 字节，而指针大小在 InnoDB 源码中设置为 6 字节，这样一共 14 字节。

那么一个页中能存放多少这样的组合，就代表有多少指针，即 0。

那么可以算出一棵高度为 2 的 B+ 树，能存放 20 条这样的数据记录。

千万级的数据存储只需要约 3 层 B+ 树，查询数据时，每加载一页（page）代表一次 IO。所以说，根据主键 id 索引查询约 3 次 IO 便可以找到目标结果。

对于一些复杂的查询，可能需要走二级索引，那么通过二级索引查找记录最多需要花费多少次 IO 呢？
首先，从二级索引 B+ 树中，根据 name 找到对应的主键 id：

然后，再根据主键 id 从聚簇索引查找到对应的记录。如上图所示，二级索引有 3 层，聚簇索引有 3 层，那么最多花费的 IO 次数是：3+3=6。

聚簇索引默认是主键，如果表中没有定义主键，InnoDB 会选择一个唯一的非空索引代替。
如果没有这样的索引，InnoDB 会隐式定义一个主键来作为聚簇索引。这也是为什么 InnoDB 表必须有主键，并且推荐使用整型的自增主键！！！
InnoDB 使用的是聚簇索引，将主键组织到一棵 B+ 树中，而行数据就储存在叶子节点上。

①若使用"where id=14"这样的条件查找记录，则按照 B+ 树的检索算法即可查找到对应的叶节点，之后获得行数据。
②若对 Name 列进行条件搜索，则需要两个步骤：
第一步在辅助索引 B+ 树中检索 Name，到达其叶子节点获取对应的主键值。
第二步使用主键值在主索引 B+ 树中再执行一次 B+ 树检索操作，最终到达叶子节点即可获取整行数据。（重点在于通过其他键需要建立辅助索引）

如果MySql 引起 CPU 消耗过大，怎么优化（数据库层面，非数据库层面）

1 减少等待（避免CPU上下文切换带来的消耗）

SQL/index，使用合适的索引减少扫描的行数（需平衡索引的正收益和维护开销，空间换时间）

避免使用函数，将运算转移至易扩展的应用服务器中 如substr等字符运算，dateadd/datesub等日期运算，abs等数学函数

减少排序，利用索引取得有序数据或避免不必要排序 如union all代替 union，order by 索引字段等

禁止类型转换，使用合适类型并保证传入参数类型与数据库字段类型绝对一致 如数字用tiny/int/bigint等，必需转换的在传入数据库之前在应用中转好

简单类型，尽量避免复杂类型，降低由于复杂类型带来的附加运算。更小的数据类型占用更少的磁盘、内存、cpu缓存和cpu周期

index，优化索引，减少不必要的表扫描 如增加索引，调整组合索引字段顺序，去除选择性很差的索引字段等等
table，合理拆分，适度冗余 如将很少使用的大字段拆分到独立表，非常频繁的小字段冗余到“引用表”
SQL，调整SQL写法，充分利用现有索引，避免不必要的扫描，排序及其他操作 如减少复杂join，减少order by，尽量union all，避免子查询等
数据类型，够用就好，减少不必要使用大字段 如tinyint够用就别总是int，int够用也别老bigint，date够用也别总是timestamp

4 减少query请求量（非数据库本身）
适当缓存，降低缓存数据粒度，对静态并被频繁请求的数据进行适当的缓存 如用户信息，商品信息等
优化实现，尽量去除不必要的重复请求 如禁止同一页面多次重复请求相同数据的问题，通过跨页面参数传递减少访问等
合理需求，评估需求产出比，对产出比极端底下的需求合理去除

5 升级cpu若经过减少计算和减少等待后还不能满足需求，cpu利用率还高T_T 是时候拿出最后的杀手锏了，升级cpu，是选择更快的cpu还是更多的cpu了？

低延迟（快速响应），需要更快的cpu（每个查询只能使用一个cpu）
高吞吐，同时运行很多查询语句，能从多个cpu处理查询中收益

MySql 死锁问题如何解决

1 两个 or 两个以上事务
2 每个事务都已经持有锁并且申请新的锁
3 锁资源同时只能被同一个事务持有或者不兼容
4 事务之间因为持有锁和申请锁导致彼此循环等待

出现死锁，看MySql 死锁日志来排查问题

经典MySql 死锁案例：

可以看到两个事务 update 不存在的记录，先后获得间隙锁( gap 锁)，gap 锁之间是兼容的所以在update环节不会阻塞。两者都持有 gap 锁，然后去竞争插入意向锁。当存在其他会话持有 gap 锁的时候，当前会话申请不了插入意向锁，导致死锁。

事务之间对资源访问顺序的交替
一个用户A 访问表A（锁住了表A），然后又访问表B；另一个用户B 访问表B（锁住了表B），然后企图访问表A；这时用户A由于用户B已经锁住表B，它必须等待用户B释放表B才能继续，同样用户B要等用户A释放表A才能继续，这就死锁就产生了。

这种死锁比较常见，是由于程序的BUG产生的，除了调整的程序的逻辑没有其它的办法。仔细分析程序的逻辑，对于数据库的多表操作时，尽量按照相同的顺序进行处理，尽量避免同时锁定两个资源，如操作A和B两张表时，总是按先A后B的顺序处理， 必须同时锁定两个资源时，要保证在任何时刻都应该按照相同的顺序来锁定资源

1 合理的设计索引，区分度高的列放到组合索引前面，使业务 SQL 尽可能通过索引定位更少的行，减少锁竞争
3 避免大事务，尽量将大事务拆成多个小事务来处理，小事务发生锁冲突的几率也更小。
4 以固定的顺序访问表和行。比如两个更新数据的事务，事务 A 更新数据的顺序为 1，2;事务 B 更新数据的顺序为 2，1。这样更可能会造成死锁。
5 在并发比较高的系统中，不要显式加锁，特别是是在事务里显式加锁。如 select … for update 语句，如果是在事务里（运行了 start transaction 或设置了autocommit 等于0）,那么就会锁定所查找到的记录。
6尽量按主键/索引去查找记录，范围查找增加了锁冲突的可能性，也不要利用数据库做一些额外额度计算工作。比如有的程序会用到 “select … where … order by rand();”这样的语句，由于类似这样的语句用不到索引，因此将导致整个表的数据都被锁住。
7 优化 SQL 和表设计，减少同时占用太多资源的情况。比如说，减少连接的表，将复杂 SQL 分解为多个简单的 SQL。

减少锁粒度，减少锁时间，减少锁发生概率，避免SQL 语句太过复杂，避免修改顺序

MySql 数据存储在磁盘上是什么样子

每个 MyISAM 表都以3个文件存储在磁盘上。这些文件的名称以表名开头，以扩展名指示文件类型。

一张 InnoDB 表底层会对应2个文件在文件夹中进行数据存储。

数据库连接池到底应该设多大（中间层）

那么结论就非常简单。在一个8核的服务器上，设定连接/线程数为8能够提供最优的性能，再增加连接数就会因上下文切换的损耗导致性能下降。数据库通常把数据存储在磁盘上，磁盘又通常是由一些旋转着的金属碟片和一个装在步进马达上的读写头组成的。读/写头同一时刻只能出现在一个地方，然后它必须“寻址”到另外一个位置来执行另一次读写操作。所以就有了寻址的耗时，此外还有旋回耗时，读写头需要等待碟片上的目标数据“旋转到位”才能进行操作。使用缓存当然是能够提升性能的，但上述原理仍然成立。

在这一时间段（即"I/O等待"）内，线程是在“阻塞”着等待磁盘，此时操作系统可以将那个空闲的CPU核心用于服务其他线程。所以，由于线程总是在I/O上阻塞，我们可以让线程/连接数比CPU核心多一些，这样能够在同样的时间内完成更多的工作。

那么应该多多少呢？这要取决于磁盘。较新型的SSD不需要寻址，也没有旋转的碟片。可别想当然地认为“SSD速度更快，所以我们应该增加线程数”，恰恰相反，无需寻址和没有旋回耗时意味着更少的阻塞 ，所以更少的线程[更接近于CPU核心数]会发挥出更高的性能。只有当阻塞创造了更多的执行机会时，更多的线程数才能发挥出更好的性能

公理：你需要一个小连接池，和一个充满了等待连接的线程的队列

如果你有10000个并发用户，设置一个10000的连接池基本等于失了智。1000仍然很恐怖。即是100也太多了。你需要一个10来个连接的小连接池，然后让剩下的业务线程都在队列里等待。连接池中的连接数量应该等于你的数据库能够有效同时进行的查询任务数（通常不会高于2*CPU核心数）。

我们经常见到一些小规模的web应用，应付着大约十来个的并发用户，却使用着一个100连接数的连接池。这会对你的数据库造成极其不必要的负担。

按这个公式，你的4核i7数据库服务器的连接池大小应该为((4 * 2) + 1) = 9。取个整就算是是10吧。是不是觉得太小了？跑个性能测试试一下，我们保证它能轻松搞定3000用户以6000TPS的速率并发执行简单查询的场景。如果连接池大小超过10，你会看到响应时长开始增加，TPS开始下降。

连接池的大小最终与系统特性相关。

比如一个混合了长事务和短事务的系统，通常是任何连接池都难以进行调优的。最好的办法是创建两个连接池，一个服务于长事务，一个服务于短事务。

再例如一个系统执行一个任务队列，只允许一定数量的任务同时执行，此时并发任务数应该去适应连接池连接数，而不是反过来。

当超过这个时候， 会报主键冲突， 说明，当再次插入时，使用的自增ID还是 ，报主键冲突的错误
如果你的服务会经常性的插入和删除数据的话，还是存在用完的风险，建议采用bigint unsigned ，这个数字就大了

不过，还存在另一种情况，如果在创建表没有显示申明主键，会怎么办？

如果是这种情况，InnoDB会自动帮你创建一个不可见的、长度为6字节的row_id，而且InnoDB 维护了一个全局的 dictsys.row_id，所以未定义主键的表都共享该row_id，每次插入一条数据，都把全局row_id当成主键id，然后全局row_id加1

该全局row_id在代码实现上使用的是bigint unsigned类型，但实际上只给row_id留了6字节，这种设计就会存在一个问题：

如果全局row_id一直涨，一直涨，直到2的48幂次-1时，这个时候再+1，row_id的低48位都为0，结果在插入新一行数据时，拿到的row_id就为0，存在主键冲突的可能性。

所以，为了避免这种隐患，每个表都需要定一个主键。

为什么delete 表数据，磁盘空间却还是被占用

凡是使用过mysql，对B+树肯定是有所耳闻的，MySQL InnoDB 中采用了 B+ 树作为存储数据的结构，也就是常说的索引组织表，并且数据时按照页来存储的。因此在删除数据时，会有两种情况：

删除数据页中的某些记录

InnoDB 直接将 R4 这条记录标记为删除，称为可复用的位置。如果之后要插入 ID 在 300 到 700 间的记录时，就会复用该位置。由此可见，磁盘文件的大小并不会减少。

通用删除整页数据也将记录标记删除，数据就复用用该位置，与删除默写记录不同的是，删除整页记录，当后来插入的数据不在原来的范围时，都可以复用位置，而如果只是删除默写记录，是需要插入数据符合删除记录位置的时候才能复用。

因此，无论是数据行的删除还是数据页的删除，都是将其标记为删除的状态，用于复用，所以文件并不会减小。
delete 删除数据时，其实对应的数据行并不是真正的删除，仅仅是将其标记成可复用的状态，所以表空间不会变小。

DELETE只是将数据标识位删除，并没有整理数据文件，当插入新数据后，会再次使用这些被置为删除标识的记录空间，可以使用OPTIMIZE TABLE来回收未使用的空间，并整理数据文件的碎片。

另外，也可以执行通过ALTER TABLE重建表

根据 hash 取模定位 DB，那模数为多少？模数要为所有此 group 组 DB 中的表数，上图总表数为 10。为什么要去表的总数？而不是 DB 总数 3 呢？

如 id=12，id%10=2；那值为 2，落到哪个 DB 库呢？这是设计是前期设定好的，那怎么设定的呢？

一旦设计定位哪个 DB 后，就需要确定落到 DB 中的哪张表呢？

我们看一下，id 在【0，1000 万】范围内的，根据上面的流程设计，1000 万以内的 id 都均匀的分配到 DB_0，DB_1，DB_2 三个数据库中的 Table_0 表中，为什么可以均匀，因为我们用了 hash 的方案，对 10 进行取模。

上面我们也提了疑问，为什么对表的总数 10 取模，而不是 DB 的总数 3 进行取模？我们看一下为什么 DB_0 是 4 张表，其他两个 DB_1 是 3 张表？

在我们安排服务器时，有些服务器的性能高，存储高，就可以安排多存放些数据，有些性能低的就少放点数据。

如果我们取模是按照 DB 总数 3，进行取模，那就代表着【0，4000 万】的数据是平均分配到 3 个 DB 中的，那就不能够实现按照服务器能力适当分配了。

按照 Table 总数 10 就能够达到，看如何达到。

上图中我们对 10 进行取模，如果值为【0，1，2，3】就路由到 DB_0，【4，5，6】路由到 DB_1，【7，8，9】路由到 DB_2。

现在小伙伴们有没有理解，这样的设计就可以把多一点的数据放到 DB_0 中，其他 2 个 DB 数据量就可以少一点。

注意：小伙伴千万不要被 DB_1 或 DB_2 中 table 的范围也是 0～4000 万疑惑了，这个是范围区间，也就是id在哪些范围内，落地到哪个表而已。

上面一大段的介绍，就解决了热点的问题，以及可以按照服务器指标，设计数据量的分配。

其实上面设计思路理解了，扩容就已经出来了；那就是扩容的时候再设计一个 group02 组，定义好此 group 的数据范围就 ok 了。
因为是新增的一个 group01 组，所以就没有什么数据迁移概念，完全是新增的 group 组，而且这个 group 组照样就防止了热点。

简单点的话，就凌晨配置，重启应用服务就行了。但如果是大型公司，是不允许的，因为凌晨也有订单的。那怎么办呢？本地 JVM 缓存怎么更新呢？

其实方案也很多，可以使用用 Zookeeper，也可以使用分布式配置，这里是比较推荐使用分布式配置中心的，可以将这些数据配置到分布式配置中心去。

这边隐含了一个关键点，那就是路由 key（如：id）的值是非常关键的，要求一定是有序的，自增的，这个就涉及到分布式唯一 id 的方案。

自增的主键的值是顺序的,所以Innodb把每一条记录都存储在一条记录的后面。当达到页面的最大填充因子时候(innodb默认的最大填充因子是页大小的15/16,会留出1/16的空间留作以后的 修改)：

①下一条记录就会写入新的页中，一旦数据按照这种顺序的方式加载，主键页就会近乎于顺序的记录填满，提升了页面的最大填充率，不会有页的浪费
②新插入的行一定会在原有的最大数据行下一行,mysql定位和寻址很快，不会为计算新行的位置而做出额外的消耗
③减少了页分裂和碎片的产生

因为uuid相对顺序的自增id来说是毫无规律可言的,新行的值不一定要比之前的主键的值要大,所以innodb无法做到总是把新行插入到索引的最后,而是需要为新行寻找新的合适的位置从而来分配新的空间

这个过程需要做很多额外的操作，数据的毫无顺序会导致数据分布散乱，将会导致以下的问题：

①写入的目标页很可能已经刷新到磁盘上并且从缓存上移除，或者还没有被加载到缓存中，innodb在插入之前不得不先找到并从磁盘读取目标页到内存中，这将导致大量的随机IO

②因为写入是乱序的,innodb不得不频繁的做页分裂操作,以便为新的行分配空间,页分裂导致移动大量的数据，一次插入最少需要修改三个页以上

所以如果我们设置的主键是乱序的，就有可能会导致数据页中的主键值大小不能满足索引使用的条件，此时就会产生页分裂
如果出现上图的数据页，我们可以发现后面数据页里的主键值比前一个数据页的主键值要小，里面的数据就会进行数据的挪动，也就是页分裂
通过页分裂，我们只要将主键为2的数据行与主键值为4的数据行互相挪动一下位置，就可以保证后面一个数据页的主键值比前一个数据页中的主键值大了，真正的页分裂可能比图中要复杂很多，但是都是通过这种形式来完成页分裂的

结论就是主键值最好是有序的，这样就可以不用页分裂，还能充分使用到索引，否则就必须进行页分裂来保证索引的使用

③由于频繁的页分裂，页会变得稀疏并被不规则的填充，最终会导致数据会有碎片

所以 uuid 和 雪花算法 应该会有 调优操作：
在把随机值（uuid和雪花id）载入到聚簇索引(innodb默认的索引类型)以后,有时候会需要做一次OPTIMEIZE TABLE来重建表并优化页的填充，这将又需要一定的时间消耗。

①别人一旦爬取你的数据库,就可以根据数据库的自增id获取到你的业务增长信息，很容易分析出你的经营情况

②对于高并发的负载，innodb在按主键进行插入的时候会造成明显的锁争用，主键的上界会成为争抢的热点，因为所有的插入都发生在这里，并发插入会导致间隙锁竞争

③Auto_Increment锁机制会造成自增锁的抢夺,有一定的性能损失

1 读磁盘IO瓶颈，热点数据多（水平垂直都可以），每次查询大量磁盘IO，降低查询速度 ： 分库和垂直分表
2 网络带宽不够，请求过多，网络IO瓶颈并发量上不来，一个数据库最多并发2000，最好保持每秒1000左右 ：分库
3 CPU瓶颈：SQL问题，如SQL中包含join，group by，order by，非索引字段条件查询等，增加CPU运算的操作 -> SQL优化，建立合适的索引，在业务Service层进行业务计算

4单表数据量太大，查询时扫描的行太多，SQL效率低，CPU率先出现瓶颈 -> 水平分表。

offset 和Limit 有什么问题 以及代替方案是什么？

正如前面段落所说的那样，OFFSET 和 LIMIT 对于数据量少的项目来说是没有问题的。
但是，当数据库里的数据量超过服务器内存能够存储的能力，并且需要对所有数据进行分页，问题就会出现。
为了实现分页，每次收到分页请求时，数据库都需要进行低效的全表扫描。

这意味着，如果你有 1 亿个用户，OFFSET 是 5 千万，那么它需要获取所有这些记录 (包括那么多根本不需要的数据)，将它们放入内存，然后获取 LIMIT 指定的 20 条结果

也就是说，为了获取一页的数据：10万行中的第5万行到第5万零20行

需要先获取 5 万行。这么做是多么低效？

这种分页查询方式会从数据库第一条记录开始扫描，所以越往后，查询速度越慢，而且查询的数据越多，也会拖慢总查询速度。

这是一种基于指针的分页。

你要在本地保存上一次接收到的主键 (通常是一个 ID) 和 LIMIT，而不是 OFFSET 和 LIMIT，那么每一次的查询可能都与此类似。

为什么？因为通过显式告知数据库最新行，数据库就确切地知道从哪里开始搜索（基于有效的索引），而不需要考虑目标范围之外的记录。
要使用这种基于游标的分页，需要有一个惟一的序列字段 (或多个)，比如惟一的整数 ID 或时间戳，但在某些特定情况下可能无法满足这个条件。

我的建议是，不管怎样都要考虑每种解决方案的优缺点，以及需要执行哪种查询。

一般情况下，在数据库中建立表的时候，强制为每一张表添加 id 递增字段，这样方便查询。

如果像是订单库等数据量非常庞大，一般会进行分库分表。这个时候不建议使用数据库的 id 作为唯一标识，而应该使用分布式的高并发唯一 id 生成器来生成，并在数据表中使用另外的字段来存储这个唯一标识。

使用先使用范围查询****定位 id （或者索引），然后再使用索引进行定位数据，能够提高好几倍查询速度。即先 select id，然后再 select *；

这种方式已经不属于查询优化，这儿附带提一下。

对于使用 id 限定优化中的问题，需要 id 是连续递增的，但是在一些场景下，比如使用历史表的时候，或者出现过数据缺失问题时，可以考虑使用临时存储的表来记录分页的id，使用分页的id来进行 in 查询。这样能够极大的提高传统的分页查询速度，尤其是数据量上千万的时候。

关于丢数据和返回不稳定的一些说明，最稳定的是第三种，其余不同数据库会有不同表现

方法1: 直接使用数据库提供的SQL语句
适应场景: 适用于数据量较少的情况(元组百/千级)
原因/缺点: 全表扫描,速度会很慢 且 有的数据库结果集返回不稳定(如某次返回1,2,3,另外的一次返回2,1,3). Limit限制的是从结果集的M位置处取出N条输出,其余抛弃.

方法2: 建立主键或唯一索引, 利用索引(假设每页10条)
适应场景: 适用于数据量多的情况(元组数上万)
原因: 索引扫描,速度会很快. 有朋友提出: 因为数据查询出来并不是按照pk_id排序的，所以会有漏掉数据的情况，只能方法3

MySql千万数据10秒批量插入

互联网项目中MySql 应该选用什么事务隔离级别

要从主从复制讲起,基于binlog 复制的，binlog是一个记录数据库更改的文件。
为什么 项目中不适用读未提交 和串行化？
互联网的分布式方案，多采用最终一致性的事务解决方案!

RR 和RC 该怎么选取？

MySql 如果每次更新操作都需要写进磁盘，然后磁盘也要先找到对应的那条数据，然后更新，整个过程IO成本，查找成本很高，为了解决这个问题，MySql在设计的时候就用了类似饭店记账的思路来更新效率。

其实就是MySQL里常说的WAL技术，WAL的全称是Write-Ahead Logging，它的关键点就是先写日志，再写磁盘，也就是先写小黑板，等不忙的时候再写账本。

需要注意的是，先写日志的写日志，其实也是写磁盘，只是写日志是顺序磁盘，速度非常快。

具体的情况就是，当有一条记录需要更新的时候，InnoDB引擎就会先把记录写到redo log里面，并更新内存，这个时候更新就算完成了，InnoDB引擎会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往在系统比较空闲的时候做，就像打烊了以后写账本一样。

同时，将赊账记录在小黑板上，如果赊账的不多，可以等打烊了以后再记录账本，如果赊账的特别多，小黑板写满了，这个时候掌柜就要放下手上的活，先把黑板上的部分赊账记录更新到账本上，然后将记录好的信息从小黑板上擦掉，为记录新的赊账腾出地方。

MySQL于这个也是类似的，InnoDB的redo log是固定大小的，比如我们可以分配一组4个文件，每个文件的大小都是1GB，那么总共就可以记录4GB的操作，从头开始写，写到末尾就又从开头循环写，write pos是当前记录的位置，一边写一边后移，写到3号文件末尾后就回到0号文件开头，checkpoint是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据库中。
write pos和checkpoint之间的是“小黑板”上还空着的部分，可以用来记录更新的操作，如果write pos追上了checkpoint，表示“黑板“写满了，这个时候不能再执行新的更新，得停下先擦掉一些记录，把check point推进一下。

redo log是InnoDB引擎所特有的，所以我们在使用InnoDB引擎创建表时，如果数据库发生异常重启，之前提交的记录都不会丢失，InnoDB就是因为有了redo log才有了crash-safe的能力。

crash-safe简单来讲，就好比饭店掌柜的把赊账记录在小黑板上或者账本上，之后饭店突然停业了几天，重新开业后，依然可以通过小黑板和账本上的数据核算赊账账目，

MySql 整体看来有两部分
一部分是Server 层，主要做的就是MySql功能层面的事情， Server 层的日志成为binlog。
还有一部分是引擎层，负责存储相关的具体事情。redo log 是innoDB 引擎特有的日志。

2 redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog是罗技日志，记录的是这个语句的原始逻辑，比如“給ID=2 这一行的 c 字段加1”

3 redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。追加写是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

MySql 大体上来看可以分为Server 层和存储引擎两部分
server层：包含 连接器，查询缓存，分析器，优化器执行器等，覆盖了MySql的大部分核心服务功能，以及所有的内置函数，所有的跨存储引擎的功能都在这一层实现，比如存储过程，触发器，视图等

存储引擎层：负责数据的存储和提取，其架构模式是插件式的，支持InnoDB，MyISAM，Memory等多个存储引擎。

关键字：长连接以及短连接，内存溢出，发生异常重启 ， 解决办法。
关键字：缓存如何存放，怎么过期，如何使用缓存，版本过期问题

关键字： 执行方案也就定下来了

关键字：对表进行权限校验，而连接器验证的是用户的身份。

pgsql中怎么遍历数据库 内容精选 换一换

• 数据库安全审计采用旁路部署模式，通过在数据库或应用系统服务器上部署数据库安全审计Agent，获取访问数据库流量、将流量数据上传到审计系统、接收审计系统配置命令和上报数据库状态监控数据，实现对ECS/BMS自建数据库的安全审计。 审计ECS/BMS自建数据库架构图如图1所示。

• Redis)提供了多种实例规格，不同的实例规格和节点数量拥有着不同的性能。本章节总结了一些实践经验，帮助您决策如何选择GaussDB(for

pgsql中怎么遍历数据库 相关内容

• NoSQL是一款基于计算存储分离架构的分布式多模NoSQL数据库服务。在云计算平台高性能、高可用、高可靠、高安全、可弹性伸缩的基础上，提供了一键部署、备份恢复、监控报警等服务能力。 云数据库 GaussDB NoSQL目前包含GaussDB(for

• 600亿条归档SQL语句存储 数据库实例通过数据库IP+数据库端口计量。 如果同一数据库IP具有多个数据库端口，数据库实例数为数据库端口数。1个数据库IP只有1个数据库端口，即为一个数据库实例；1个数据库IP具有N个数据库端口，即为N个数据库实例。 例如：用户有2个数据库资产分别为IP

pgsql中怎么遍历数据库 更多内容

• 在左侧导航树中，选择“数据库列表”，进入数据库列表界面。 在“选择实例”下拉列表框中，选择需要添加数据库的实例。在数据库列表框左上方，单击“添加数据库”。 在弹出的对话框中，按表1所示信息填写数据库参数，如图2所示。 数据库安全审计支持“UTF-8”和“GBK”两种数据库字符集的编码格式，请根据业务情况选择编码格式。

•  我们知道，SQL是关系型数据库的查询语言，但是图数据库的查询语言并没有复用SQL。这是因为本质上图数据库处理的是高维数据，而SQL所适用的是二维的数据结构，其并不擅

• password: 使用root用户连接数据库实例，示例如下：

• 范围切分这是一种「连续式」的切分方式。 比如根据时间（createTime）切分的话，我们可以按年月来分，order_201901一个库，order_201902一个库，以此类推。

• . 子进程做数据持久化，它不会修改现有的内存数据结构，它只是对数据结构进行遍历读取，然后序列化写到磁盘中。但是父进程不一样，它必须持续服务客户端请求，然后对内存数据结构进行不间断的修改。 这个时候就会使用操作系统的 COW 机制来进行数据段页面的分离。数据段是由很多操作系统

• N。 书写规范 变量命名规则： 过程、函数的输入参数格式宜为：IN_参数名，参数名宜使用大写。 过程、函数的输出参数格式宜为：OUT_参数名，参数名宜使用大写。 过程、函数得输入输出参数格式宜为：IO_参数名，参数名宜使用大写。 过程、函数得程序中用到的变量宜由v_变量名组成，变量名宜使用小写。

• 请参见设置告警规则。 数据库磁盘空间不足的原因和解决方案，请参见数据超过了RDS实例的最大存储容量怎么办。 磁盘扩容期间，服务不中断。云数据库RDS服务只支持扩容磁盘存储空间大小，不支持变更存储类型。 约束限制 账户余额大于等于0元，才可进行扩容。 云数据库RDS实例支持无限次扩容。

• Masking)功能。针对某些敏感信息（如身份证号、手机号、银行卡号等），通过应用脱敏函数进行原始数据的变形改写，实现敏感隐私数据的可靠保护，从而增强产品在数据安全和隐私保护方面的能力。 用户可以在

• 部分MySQL数据库版本可能不支持以上查询命令。 若执行以上命令没有获取到用户密码信息，请执行命令。

• DLI将Flink作业从数据仓库服务（DWS）中读取数据。DWS数据库内核兼容PostgreSQL，PostgreSQL数据库可存储更加复杂类型的数据，支持空间信息服务、多版本并发控制（MVCC）、高并发，适用场景包括位置应用、金融保险、互联网电商等。

• 可用状态，使数据库恢复正常的写入操作。 建议您设置“磁盘使用率”指标的告警规则，及时了解磁盘使用情况，起到预警作用，具体请参见设置告警规则。 数据库磁盘空间不足的原因和解决方案，请参见数据超过了RDS实例的最大存储容量怎么办。 磁盘扩容期间，服务不中断。云数据库RDS服务只支持扩

• 虚拟内存机制就是暂时把不经常访问的数据(冷数据)从内存交换到磁盘中，从而腾出宝贵的内存空间用于其它需要访问的数据(热数据)。通过VM功能可以实现冷热数据分离，使热数据仍在内存中、冷数据保存到磁盘。这样就可以避免因为内存不足而造成访问速度下降的问题。 Redis的常用应用场景 缓存 排行榜 计数器应用 共享Session

• 为什么B+树比B树更适合实现数据库索引？ 由于B+树的数据都存储在叶子结点中，叶子结点均为索引，方便扫库，只需要扫一遍叶子结点即可，但是B树因为其分支结点同样存储着数据，我们要找到具体的数据，需要进行一次中序遍历按序来扫，所以B+树更加适合在区间查询的情况，而在数据库中基于范围的查询是

• 成之后将对应表的数据回写到原实例的目标表，恢复时长和实例的数据量有关，平均恢复速率为20MB/s。 由于需要对实例的所有数据进行备份及恢复操作，对于数据量较大的实例，所需时间较长，请耐心等待。通过表级时间点恢复备份，将不会导致实例数据被覆盖，您可以根据需要恢复库表。 使用限制 该功能目前仅支持MySQL引擎。

• DLI将Flink作业的输出数据输出到数据仓库服务（DWS）中。DWS数据库内核兼容PostgreSQL，PostgreSQL数据库可存储更加复杂类型的数据，支持空间信息服务、多版本并发控制（MVCC）、高并发，适用场景包括位置应用、金融保险、互联网电商等。

• N。 书写规范 变量命名规则： 过程、函数的输入参数格式宜为：IN_参数名，参数名宜使用大写。 过程、函数的输出参数格式宜为：OUT_参数名，参数名宜使用大写。 过程、函数得输入输出参数格式宜为：IO_参数名，参数名宜使用大写。 过程、函数得程序中用到的变量宜由v_变量名组成，变量名宜使用小写。

• 目录 使用平面文件进行数据存储 平面文件的优点 平面文件的缺点 平面文件示例 使用 SQLite 持久化数据 创建数据库结构 使用 SQL 与数据库交互 使用 SQL 构建数据库 使用 SQL 创建表 使用 SQL 维护数据库 建立关系 一对多关系 多对多关系

• 在创建一个表后，表中并没有数据，在使用这个表之前，需要向表中插入数据。本小节介绍如何使用INSERT命令插入一行或多行数据，及从指定表插入数据。如果有大量数据需要批量导入表中，请参考导入数据。 背景信息 服务端与客户端使用不同的字符集时，两者字符集中单个字符的长度

• 可以通过复制数据库来拆分数据。大多数主要的关系数据库系统都有某种类型的复制功能。MySQL是通过主从数据库的概念来实现复制功能的。所谓主数据库就是执行写操作的主要数据库，从数据库是主数据库的只读副本。主数据库会把更新、插入、删除等操作记录在二进制的日志中。每个从数据库则是从主数据

• 主要讲述数据库的数据类型、常用函数和表达式计算等数据库应用开发的必备基础知识 第5章 SQL语言 主要讲述SQL语言的特点、功能；SQL数据定义语句、数据操纵语句应用等内容 第6章 数据库 主要讲述数据库种类；讲述存储引擎；数据库创建及维护方法等内容 第7章 索引 主要讲述文件组织、索引、索引的类型以及创建索

• 问题。 分布式SQL支持 常见的单分片SQL，这两者都能很好支持。NewSQL数据库由于定位与目标是一个通用的数据库，所以支持的SQL会更完整，包括跨分片的join、聚合等复杂SQL。中间件模式多面向应用需求设计，不过大部分也支持带拆分键SQL、库表遍历、单库join、聚合、

• PostgreSQL数据库服务端相同版本的数据库客户端，PostgreSQL数据库或客户端会自带pg_dump和psql工具。 导出数据 要将已有的PostgreSQL数据库迁移到云数据库RDS，需要先对它进行导出。 相应导出工具需要与数据库引擎版本匹配。 数据库迁移为离线迁移，您需要停止使用源数据库的应用程序。

• 目前它还只是关系型数据库的补充，它在数据的一致性，数据的安全性，查询的复杂性问题上和关系型数据库还存在一定差距。 MySQL是关系性数据库中的一种，查询功能强，数据一致性高，数据安全性高，支持二级索引。但性能方面稍逊与MongoDB，特别是百万级别以上的数据，很容易出现查询慢的

• 数据集都是作为数据库的临时数据容器，可以实现数据库的断开式访问。此时数据库是数据集的数据源，你可以一次性将需要的数据装进数据集，等操作完了再一并更新到数据库中，这就是数据集断开式访问方式。另外，数据集的数据源并不一定是数据库，数据集的数据源可以是文本、XML文

• 件恢复数据。 通过数据复制服务的实时迁移功能，将云下MySQL数据库迁移到华为云RDS，具体请参见入云迁移。 本地的SQL Server备份文件恢复到实例 将本地SQL Server数据库中“.bak”格式的备份文件，先上传到OBS自建桶中，具体请参见上传文件。 通过数据复制服务

• 问题。 分布式SQL支持 常见的单分片SQL，这两者都能很好支持。NewSQL数据库由于定位与目标是一个通用的数据库，所以支持的SQL会更完整，包括跨分片的join、聚合等复杂SQL。中间件模式多面向应用需求设计，不过大部分也支持带拆分键SQL、库表遍历、单库join、聚合、

• rver层：大多数MySQL的核心服务功能都在这一层，包括查询解析、分析、优化、缓存以及所有的内置函数（例如，日期、时间、数学和加密函数），所有跨存储引擎的功能都在这一层实现：存储过程、触发器、视图等。存储引擎层：第三层包含了存储引擎。存储引擎负责MySQL中数据的存储和提取。S

• concurrent包下面的所有的类都是安全失败的，在遍历过程中，如果已经遍历的数组上的内容变化了，迭代器不会抛出

• 一、概述 深入学习MySQL，从概览MySQL逻辑架构开始。 首先来看一下MySQL的逻辑架构图： MySQL最重要、最与众不同的特性就是它的存储引擎架构，这种架构将：查询处理、其他系统任务、数据的存储与提取 三部分分离。所以，带来的好处就是可以在使用时根据性能、特性，以及其他需求来选择数据存储方式。

• 5 索引的作用 加快数据的访问将随机io变成顺序io大大减少了服务器需要扫描的数据量帮助服务器避免排序和临时表减少io次数，提高磁盘寿命 索引缺点 加了索引之后查询会更快，但是当数据量大的时候，增删改就会变慢；因为每次修改数据时除了数据本身，数据库还需要维护索引的那颗B+树；

pgsql中怎么遍历数据库

提交成功！非常感谢您的反馈，我们会继续努力做到更好 反馈提交失败！请稍后重试！