AI 助理
备案控制台
开发者社区 数据库 文章 正文

MySQL：Innodb恢复的学习笔记

2018-08-27 1970
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
云数据库 RDS MySQL，集群系列 2核4GB
推荐场景：
搭建个人博客
RDS MySQL Serverless 基础系列，0.5-2RCU 50GB
推荐场景：
学生管理系统数据库设计 搭建个人博客
云数据库 RDS PostgreSQL，集群系列 2核4GB
简介：

本文只是记录无可读性,供自己参考

MySQL · 引擎特性 · InnoDB 崩溃恢复过程

enum {
    SRV_FORCE_IGNORE_CORRUPT = 1,    /*!< let the server run even if it
                    detects a corrupt page */
    SRV_FORCE_NO_BACKGROUND    = 2,    /*!< prevent the main thread from
                    running: if a crash would occur
                    in purge, this prevents it */
    SRV_FORCE_NO_TRX_UNDO = 3,    /*!< do not run trx rollback after
                    recovery */
    SRV_FORCE_NO_IBUF_MERGE = 4,    /*!< prevent also ibuf operations:
                    if they would cause a crash, better
                    not do them */
    SRV_FORCE_NO_UNDO_LOG_SCAN = 5,    /*!< do not look at undo logs when
                    starting the database: InnoDB will
                    treat even incomplete transactions
                    as committed */
    SRV_FORCE_NO_LOG_REDO = 6    /*!< do not do the log roll-forward
                    in connection with recovery */
};

innodb中的 3个lsn

innodb的lsn和oracle的scn一样，是一个重要的概念。比如

  • 在flush list中正是是使用low lsn作为链表的条件
    参考buf_page_t中的lsn_t oldest_modification;
  • 在checkpoint中记录的也是lsn
    参考宏
#define LOG_CHECKPOINT_NO        0
#define LOG_CHECKPOINT_LSN        8
#define LOG_CHECKPOINT_OFFSET        16
#define LOG_CHECKPOINT_LOG_BUF_SIZE    24
  • 在物理文件中每个块最后的刷新lsn
    参考宏FIL_PAGE_LSN
  • 在写日志落盘的时候也是以lsn为标准的
    参考函数log_write_up_to

实际上lsn就是表示的日志量的字节数，是一个累加的值，在5.7中表现为:

/* Type used for all log sequence number storage and arithmetics */
typedef    ib_uint64_t        lsn_t;

及一个8字节非负的整数。最大值及2的64次方。有了这种物理上概念，lsn很容易换算为当前日志的偏移量。

下面描述一下和检查点相关的几个lsn

  • ibdata第一个块FIL中的lsn(flush lsn):ibdata的26后面8字节是在innodb 干净关闭的时候进行更新的，如果不正常关闭不会进行写入(FIL_PAGE_FILE_FLUSH_LSN)
  • redolog中MLOG_CHECKPOINT的lsn: redolog MLOG_CHECKPOINT lsn的写入是在每次checkpoint的时候同步写入的.干净关闭会更新。
  • redolog header中的lsn:是在每次checkpoint的时候异步写入的在MLOG_CHECKPOINT写入之后.干净关闭会更新。
    我们表示为lsn1/lsn2/lsn3

正常关闭3个lsn是相等的，如果非正常关闭innodb,lsn1不会更新，因此lsn3必然不和lsn1相等，则判定需要进行carsh recovery。

if (checkpoint_lsn != flush_lsn) {

    ......
        if (!recv_needed_recovery) {

            ib::info() << "The log sequence number " << flush_lsn
                << " in the system tablespace does not match"
                " the log sequence number " << checkpoint_lsn
                << " in the ib_logfiles!"; //出现这个警告说明需要恢复了，因为没有干净的关闭数据库，那么flush_lsn一定比checkpoint_lsn小

            if (srv_read_only_mode) {
                ib::error() << "Can't initiate database"
                    " recovery, running in read-only-mode.";
                log_mutex_exit();
                return(DB_READ_ONLY);
            }
            recv_init_crash_recovery(); //初始化
        }
    }

MLOG_CHECKPOINT

  • log_checkpoint 函数由master线程调用，以及关闭数据库的时候调用，不断的向redo log中写入MLOG_CHECKPOINT和MLOG_FILE_NAME

log_group_checkpoint 写入checkpoint信息到log header

#0  mtr_t::commit_checkpoint (this=0x7fff761fb830, checkpoint_lsn=697558445) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/mtr/mtr0mtr.cc:592
#1  0x0000000001ceb4b9 in fil_names_clear (lsn=697558445, do_write=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/fil/fil0fil.cc:7067
#2  0x0000000001a521cc in log_checkpoint (sync=true, write_always=false) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1927
#3  0x0000000001b856f2 in srv_master_do_idle_tasks () at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0srv.cc:2596
#4  0x0000000001b85b6b in srv_master_thread (arg=0x0) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0srv.cc:2744
#5  0x0000003f74807aa1 in start_thread () from /lib64/libpthread.so.0
#6  0x0000003f740e8bcd in clone () from /lib64/libc.so.6

正常innodb运行的情况下 checkpoint是由master线程触发。我们知道脏数据通过page clean线程和lru manager线程是在不断写盘的，那么在进行异常重启的的时候我们必须要知道一个恢复的起点，但是这个起点是不能记录在内存中必要固化到磁盘，恢复的时候读取这个点以后的redo进行恢复，而checkpoint就是完成这个事情下面是checkpoint的执行流程。

正常情况下master会每秒进行检查点其作用有:(参考log_checkpoint函数)
1、检查是否有自上次检查点以来的脏数据写盘了
2、如果有则在redo里面会为每个修改过的文件写入MLOG_FILE_NAME,完成后写入一个总的MLOG_CHECKPOINT(参考fil_names_clear函数)
MLOG_FILE_NAME主要记录至上次检查点以来更改过的数据文件
MLOG_CHECKPOINT主要记录检查点的lsn
3、如果有则在redo header中写入相应的检查点信息包含(异步写)(参考log_group_checkpoint函数)

Log sequence number 697794162
Log flushed up to 697794162
Pages flushed up to 697794162
Last checkpoint at 697794153

697794162-697794153 = 9 刚好是MLOG_CHECKPOINT的长度
oldest_lsn <= log_sys->last_checkpoint_lsn + SIZE_OF_MLOG_CHECKPOINT
SIZE_OF_MLOG_CHECKPOINT=9

redo的写入有6个途径:
1、master 线程每秒调用 栈帧(可能是idle可能是active 和检测是否需要插入缓存合并有关)
2、master 线程每秒checkpoint调用 (可能是idle可能是active 和检测是否需要插入缓存合并有关)
3、page clean 线程调用 栈帧 / Force the log to the disk before writing the modified block /
4、主线程commit 调用 栈帧
5、innodb shutdown
6、redo buffer不足

1、master线程调用 栈帧(可能是idle可能是active 和检测是否需要插入缓存合并有关)

#0  log_group_write_buf (group=0x33f29f8, buf=0x7fffa5b38000 "\200\024", len=512, pad_len=0, start_lsn=697764864, new_data_offset=166)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1145
#1  0x0000000001a50f95 in log_write_up_to (lsn=697765068, flush_to_disk=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1493
#2  0x0000000001a51163 in log_buffer_sync_in_background (flush=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1553
#3  0x0000000001b84bd1 in srv_sync_log_buffer_in_background () at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0srv.cc:2312
#4  0x0000000001b85666 in srv_master_do_idle_tasks () at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0srv.cc:2586
#5  0x0000000001b85b6b in srv_master_thread (arg=0x0) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0srv.cc:2744

2、master 线程checkpoint调用 (可能是idle可能是active 和检测是否需要插入缓存合并有关)

#0  log_group_write_buf (group=0x33f29f8, buf=0x7fffa5a38000 "\200\024\002", len=1024, pad_len=0, start_lsn=697789952, new_data_offset=139)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1145
#1  0x0000000001a50f95 in log_write_up_to (lsn=697790725, flush_to_disk=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1493
#2  0x0000000001a52247 in log_checkpoint (sync=true, write_always=false) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1934
#3  0x0000000001b856f2 in srv_master_do_idle_tasks () at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0srv.cc:2596
#4  0x0000000001b85b6b in srv_master_thread (arg=0x0) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0srv.cc:2744

3、page clean 线程调用 栈帧 / Force the log to the disk before writing the modified block /

#0  log_group_write_buf (group=0x33f29f8, buf=0x7fffa5a38000 "\200\024\002", len=13312, pad_len=1024, start_lsn=697778176, new_data_offset=468)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1145
#1  0x0000000001a50f95 in log_write_up_to (lsn=697790015, flush_to_disk=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1493
#2  0x0000000001c704c7 in buf_flush_write_block_low (bpage=0x7fffc0cae940, flush_type=BUF_FLUSH_LIST, sync=false)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:1035
#3  0x0000000001c70cea in buf_flush_page (buf_pool=0x33247d8, bpage=0x7fffc0cae940, flush_type=BUF_FLUSH_LIST, sync=false)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:1237
#4  0x0000000001c717f4 in buf_flush_try_neighbors (page_id=..., flush_type=BUF_FLUSH_LIST, n_flushed=0, n_to_flush=25)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:1466
#5  0x0000000001c71b57 in buf_flush_page_and_try_neighbors (bpage=0x7fffc0cae940, flush_type=BUF_FLUSH_LIST, n_to_flush=25, count=0x7fffa02867c0)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:1558
#6  0x0000000001c72862 in buf_do_flush_list_batch (buf_pool=0x33247d8, min_n=25, lsn_limit=18446744073709551615)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:1846
#7  0x0000000001c72cb6 in buf_flush_batch (buf_pool=0x33247d8, flush_type=BUF_FLUSH_LIST, min_n=25, lsn_limit=18446744073709551615)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:1926
#8  0x0000000001c73104 in buf_flush_do_batch (buf_pool=0x33247d8, type=BUF_FLUSH_LIST, min_n=25, lsn_limit=18446744073709551615, n_processed=0x7fffa0286938)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:2071
#9  0x0000000001c734ee in buf_flush_lists (min_n=25, lsn_limit=18446744073709551615, n_processed=0x7fffa02869c8)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:2202
#10 0x0000000001c76a97 in buf_flush_page_cleaner_coordinator (arg=0x0) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:3362

4、主线程commit 调用 栈帧

#0  log_group_write_buf (group=0x33f29f8, buf=0x7fffa5a38000 "\200\024\002", len=2560, pad_len=0, start_lsn=697762816, new_data_offset=230)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1145
#1  0x0000000001a50f95 in log_write_up_to (lsn=697765030, flush_to_disk=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1493
#2  0x0000000001a51087 in log_buffer_flush_to_disk (sync=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1524
#3  0x00000000019a9157 in innobase_flush_logs (hton=0x2e9fdd0, binlog_group_flush=true)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/handler/ha_innodb.cc:4407
#4  0x0000000000f65893 in flush_handlerton (thd=0x0, plugin=0x7ffff03588e8, arg=0x7ffff0358944) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/handler.cc:2606
#5  0x00000000015d7716 in plugin_foreach_with_mask (thd=0x0, func=0xf65835 <flush_handlerton(THD*, plugin_ref, void*)>, type=1, state_mask=4294967287, 
    arg=0x7ffff0358944) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_plugin.cc:2318
#6  0x0000000000f658ef in ha_flush_logs (db_type=0x0, binlog_group_flush=true) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/handler.cc:2617
#7  0x000000000185733d in MYSQL_BIN_LOG::process_flush_stage_queue (this=0x2e02c80, total_bytes_var=0x7ffff0358a88, rotate_var=0x7ffff0358a87, 
    out_queue_var=0x7ffff0358a78) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:8541
#8  0x000000000185899f in MYSQL_BIN_LOG::ordered_commit (this=0x2e02c80, thd=0x7fff2c000b70, all=false, skip_commit=false)
    at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:9189
#9  0x000000000185700c in MYSQL_BIN_LOG::commit (this=0x2e02c80, thd=0x7fff2c000b70, all=false) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:8440
#10 0x0000000000f63df8 in ha_commit_trans (thd=0x7fff2c000b70, all=false, ignore_global_read_lock=false)

入口函数
innobase_start_or_create_for_mysql

recv_recovery_from_checkpoint_start

1、此函数需要输入flush的lsn及脏数据写入到的位置

这个数据从FIL_PAGE_FILE_FLUSH_LSN中读取，这个值
只在ibdata的第一个page有效其他均为0,他的读取来自于
函数Datafile::validate_first_page，
其中
*flush_lsn = mach_read_from_8(
m_first_page + FIL_PAGE_FILE_FLUSH_LSN);


其写入由函数  正常shutdown才会写入,非正常关闭不会写入，正常运行检查点也不会写入
fil_write_flushed_lsn 写入
mach_write_to_8(buf + FIL_PAGE_FILE_FLUSH_LSN, lsn);

栈帧
    #0  fil_write_flushed_lsn (lsn=696973727) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/fil/fil0fil.cc:1946
    #1  0x0000000001a538a7 in logs_empty_and_mark_files_at_shutdown () at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:2464
    #2  0x0000000001b915a9 in innobase_shutdown_for_mysql () at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0start.cc:2803
    #3  0x00000000019a8ffc in innobase_end (hton=0x2e9edd0, type=HA_PANIC_CLOSE) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/handler/ha_innodb.cc:4360
    #4  0x0000000000f62621 in ha_finalize_handlerton (plugin=0x3015cd0) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/handler.cc:813
    #5  0x00000000015d3d25 in plugin_deinitialize (plugin=0x3015cd0, ref_check=true) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_plugin.cc:995
    #6  0x00000000015d410e in reap_plugins () at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_plugin.cc:1077
    #7  0x00000000015d6073 in plugin_shutdown () at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_plugin.cc:1845
    #8  0x0000000000ebf7eb in clean_up (print_message=true) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/mysqld.cc:1336
    #9  0x0000000000ec701b in mysqld_main (argc=98, argv=0x2e9cf08) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/mysqld.cc:5386
    #10 0x0000000000ebd604 in main (argc=10, argv=0x7fffffffe458) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/main.cc:25

2、此函数首先建立红黑树用于恢复并且做 force recovery判断

   (srv_force_recovery >= SRV_FORCE_NO_LOG_REDO) 
   然后调用 
   recv_find_max_checkpoint 此函数就是找到最大的checkpoint lsn、redo文件,以及field 就是相对于一个日志而讲所在的offset set (512*1 or 512*3)_
   读取如下：
                   group->lsn = mach_read_from_8(
                  buf + LOG_CHECKPOINT_LSN);
                group->lsn_offset = mach_read_from_8(
                  buf + LOG_CHECKPOINT_OFFSET);
                checkpoint_no = mach_read_from_8(
                  buf + LOG_CHECKPOINT_NO);

3、recv_group_scan_log_recs

   循环读取64K(RECV_SCAN_SIZE)日志到redo buffer(log_group_read_log_seg)
   recv_scan_log_recs
     本函数将64K 的redo 通过每个512 bytes block大小循环加入到(recv_sys_add_to_parsing_buf) 扫描到parse buffer 
     代码片段拷贝
          ut_memcpy(recv_sys->buf + recv_sys->len,
              log_block + start_offset, end_offset - start_offset);
            
           当每次扫描了64K*80的日志量的时候会输出，级5M
           ib::info() << "Doing recovery: scanned up to"
                " log sequence number " << scanned_lsn;
     并且进行分析对这加入到 parse buffer的日志进行分析(recv_parse_log_recs) /其中parse buffer 为2M(宏RECV_PARSING_BUF_SIZE大小)
        recv_parse_log_recs函数对每次加入 parse buffer的64k进行分析主要分析是MLOG_SINGLE_REC_FLAG还是MLOG_MULTI_REC_END 同时确认MLOG_MULTI_REC_END
        是否完整，完成后加入到hash table，函数是调用recv_parse_log_rec进行 (type spaceid page_no data)的剥离。

那么recv_group_scan_log_recs为第一层循环，循环扫描64K日志到redo buffer
然后调用recv_scan_log_recs以block单位(512b)大小循环加入到parse buffer，这是通过函数recv_sys_add_to_parsing_buf完成
等到64k加入到parse buffer后调用recv_parse_log_recs函数对每次加入 parse buffer的64k进行分析，分析是循环以record为单位的，主要分析MLOG_SINGLE_REC_FLAG还是MLOG_MULTI_REC_END，同时确保MLOG_MULTI_REC_END记录是完整的。完成后recv_parse_log_recs函数 还要将其加入到hash table函数为recv_add_to_hash_table，本函数是通过recv_parse_log_rec进行 (type spaceid page_no data)的剥离。

recv_apply_hashed_log_recs 最后完成分析完成后的日志应用，从hash table中

作者微信：
微信.jpg

文章标签：
云数据库 RDS MySQL 版
日志服务
关系型数据库
SQL
监控
MySQL
关键词：
云数据库 RDS MySQL 版innodb
mysql innodb
云数据库 RDS MySQL 版学习笔记
innodb mysql
云数据库 RDS MySQL 版恢复
相关实践学习
如何在云端创建MySQL数据库
开始实验后，系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心，利用清洁计算为万物互联的新世界提供源源不断的能源动力，目前开服的区域包括中国（华北、华东、华南、香港）、新加坡、美国（美东、美西）、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程，来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品：云服务器ECS 云服务器 ECS（Elastic Compute Service）是一种弹性可伸缩的计算服务，助您降低 IT 成本，提升运维效率，使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
重庆八怪
目录
相关文章
zzy的aly
|
1月前
|
存储 SQL 关系型数据库
Mysql学习笔记(二)：数据库命令行代码总结
这篇文章是关于MySQL数据库命令行操作的总结，包括登录、退出、查看时间与版本、数据库和数据表的基本操作（如创建、删除、查看）、数据的增删改查等。它还涉及了如何通过SQL语句进行条件查询、模糊查询、范围查询和限制查询，以及如何进行表结构的修改。这些内容对于初学者来说非常实用，是学习MySQL数据库管理的基础。
zzy的aly
131 6
赵渝强老师
|
14天前
|
存储 Oracle 关系型数据库
【赵渝强老师】MySQL InnoDB的数据文件与重做日志文件
本文介绍了MySQL InnoDB存储引擎中的数据文件和重做日志文件。数据文件包括`.ibd`和`ibdata`文件，用于存放InnoDB数据和索引。重做日志文件（redo log）确保数据的可靠性和事务的持久性，其大小和路径可由相关参数配置。文章还提供了视频讲解和示例代码。
赵渝强老师
122 11
【赵渝强老师】MySQL InnoDB的数据文件与重做日志文件
赵渝强老师
|
14天前
|
存储 Oracle 关系型数据库
【赵渝强老师】MySQL InnoDB的表空间
InnoDB是MySQL默认的存储引擎，主要由存储结构、内存结构和线程结构组成。其存储结构分为逻辑和物理两部分，逻辑存储结构包括表空间、段、区和页。表空间是InnoDB逻辑结构的最高层，所有数据都存放在其中。默认情况下，InnoDB有一个共享表空间ibdata1，用于存放撤销信息、系统事务信息等。启用参数`innodb_file_per_table`后，每张表的数据可以单独存放在一个表空间内，但撤销信息等仍存放在共享表空间中。
赵渝强老师
38 6
赵渝强老师
|
14天前
|
存储 Oracle 关系型数据库
【赵渝强老师】MySQL InnoDB的段、区和页
MySQL的InnoDB存储引擎逻辑存储结构与Oracle相似，包括表空间、段、区和页。表空间由段和页组成，段包括数据段、索引段等。区是1MB的连续空间，页是16KB的最小物理存储单位。InnoDB是面向行的存储引擎，每个页最多可存放7992行记录。
赵渝强老师
34 5
赵渝强老师
|
14天前
|
存储 Oracle 关系型数据库
【赵渝强老师】MySQL的InnoDB存储引擎
InnoDB是MySQL的默认存储引擎，广泛应用于互联网公司。它支持事务、行级锁、外键和高效处理大量数据。InnoDB的主要特性包括解决不可重复读和幻读问题、高并发度、B+树索引等。其存储结构分为逻辑和物理两部分，内存结构类似Oracle的SGA和PGA，线程结构包括主线程、I/O线程和其他辅助线程。
赵渝强老师
28 0
【赵渝强老师】MySQL的InnoDB存储引擎
zzy的aly
|
1月前
|
SQL 关系型数据库 MySQL
Mysql学习笔记(三)：fetchone(), fetchmany(), fetchall()详细总结
MySQL中用于数据检索的`fetchone()`, `fetchmany()`, `fetchall()`函数的功能、SQL语句示例和应用场景。
zzy的aly
59 3
Mysql学习笔记(三)：fetchone(), fetchmany(), fetchall()详细总结
zzy的aly
|
1月前
|
SQL Ubuntu 关系型数据库
Mysql学习笔记(一)：数据库详细介绍以及Navicat简单使用
本文为MySQL学习笔记，介绍了数据库的基本概念，包括行、列、主键等，并解释了C/S和B/S架构以及SQL语言的分类。接着，指导如何在Windows和Ubuntu系统上安装MySQL，并提供了启动、停止和重启服务的命令。文章还涵盖了Navicat的使用，包括安装、登录和新建表格等步骤。最后，介绍了MySQL中的数据类型和字段约束，如主键、外键、非空和唯一等。
zzy的aly
71 3
Mysql学习笔记(一)：数据库详细介绍以及Navicat简单使用
zzy的aly
|
1月前
|
关系型数据库 MySQL 数据库
Mysql学习笔记(四)：Python与Mysql交互--实现增删改查
如何使用Python与MySQL数据库进行交互，实现增删改查等基本操作的教程。
zzy的aly
67 1
蓝易云
|
1月前
|
存储 缓存 关系型数据库
详细解析MySQL中的innodb和myisam
总之，InnoDB和MyISAM各有千秋，选择合适的存储引擎应基于对应用程序特性的深入理解，以及对性能、数据完整性和可扩展性的综合考量。随着技术发展，InnoDB因其全面的功能和日益优化的性能，逐渐成为更广泛场景下的首选。然而，在特定条件下，MyISAM依然保留其独特的价值。
蓝易云
127 0
游客mldfis24krfue
|
3月前
|
监控 关系型数据库 MySQL
在Linux中，mysql的innodb如何定位锁问题？
在Linux中，mysql的innodb如何定位锁问题？
游客mldfis24krfue
115 2

热门文章

最新文章

  • 1
    测试开启MySQL performance_schema后对性能的影响
  • 2
    RDS入门——Excel文件转存到RDS数据库实践
  • 3
    Spring Boot整合MyBatis操作mysql数据库实战（附源码 超详细）
  • 4
    MySQL全文搜索与JSON支持：高效检索与灵活数据处理
  • 5
    JDBC操作MySQL5日期类型字段的问题解决方法
  • 6
    Mariadb/Mysql TEMPORARY表
  • 7
    JDBC 驱动升级到 Version 8.0.28 连接 MySQL 的踩坑记录
  • 8
    PG+MySQL第11课-多维向量搜索
  • 9
    FAQ系列 | 启用SELinux后，PHP连接MySQL异常
  • 10
    mysql合并查询(多张表) union 和 union all
  • 1
    10个行锁、死锁案例⭐️24张加锁分析图🚀彻底搞懂Innodb行锁加锁规则！
    353
  • 2
    MySQL高可用解决方案演进：从主从复制到InnoDB Cluster架构
    317
  • 3
    mysql中MyISAM和InnoDB的区别是什么
    54
  • 4
    【MySQL系列笔记】InnoDB引擎-数据存储结构
    417
  • 5
    【MySQL】InnoDB 什么情况下会产生死锁
    192
  • 6
    详解InnoDB(2)——日志
    118
  • 7
    详解InnoDB(1)——事务
    83
  • 8
    InnoDB中的索引方案
    61
  • 9
    MySQL InnoDB引擎（下）
    55
  • 10
    MySQL InnoDB引擎（上）
    61

    • 相关课程

    更多
  • MySQL企业常见架构与调优经验分享
  • 云数据库MySQL版快速上手教程
  • 阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
  • MySQL实战进阶
  • 数据库及SQL/MySQL基础
  • 云数据库MySQL快速入门

    • 相关电子书

    更多
  • 搭建电商项目架构连接MySQL
  • 搭建4层电商项目架构，实战连接MySQL
  • PolarDB MySQL引擎重磅功能及产品能力盛大发布

    • 相关实验场景

    更多
  • 灵活弹性的PolarDB Serverless确保数据业务持续在线
  • 云端MySQL的安装及应用
  • 体验PolarDB MySQL多主集群
  • 基于ECS+RDS的在线留言系统
  • ECS服务器部署MySQL数据库
  • RDS MySQL的SQL问题诊断与调优

    • 推荐镜像

    更多
  • mysql
  • mariadb
  • postgresql
    • 下一篇
    无影云桌面