MySQL insert 语句的函数调用栈和innodb引擎的更新方式

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 RDS MySQL,高可用系列 2核4GB
简介: 研究和学习MySQL源码可能会有用,MySQL insert语句的函数调用栈

     MySQL insert 语句的函数调用栈,这个调用栈是用gdb调试MySQL时打印出来的,内容和格式上没做任何调整,MySQL的版本是5.7的最新版本5.7.35,调用的顺序是从下到上。存储引擎是innodb,学习和研究MySQL数据库源码时可以当作参考,里面的信息时相当完整的,调用的函数名称,调用函数所在的文件,调用函数在文件中具体位置(在文件中的哪一行)都十分清楚。

      MySQL数据库innodb存储引擎在执行更新时可能会采用两种不同的方式,备份更新或者是乐观更新,innodb引擎总是首先对索引内存对象加上s-latch保护,然后进行页的操作,若insert、update、delete不会导致非叶子节点的变化,即不会发生

分裂、合并、树的高度变化,则立即释放索引对象的s-latch保护,称这种模式为乐观模式。否则,立即释放索引内存对象及页上的latch,并对索引内存对象和页加x-latch保护,这种方式称为悲观方式,由于对索引对象页加了x-latch,并发在此处受到了很大的限制。

      从下面的函数跳用栈来看,这次更新使用了乐观更新,调用的函数是btr_cur_optimistic_insert。

0page_cur_insert_rec_low (current_rec=0x6<error: Cannotaccessmemoryataddress0x6>, index=0x7f24e569b6d0,
rec=0x7f24e569b720"d", offsets=0x6, mtr=0x563e03dea7eb<rec_offs_n_fields(ulintconst*)+171>)
at/root/mysql-5.7.35/storage/innobase/page/page0cur.cc:134210x0000563e03f4b9f1inpage_cur_tuple_insert (cursor=0x7f24e569be48, tuple=0x7f248001e420, index=0x7f2480012290,
offsets=0x7f24e569bdf0, heap=0x7f24e569bde8, n_ext=0, mtr=0x7f24e569c270, use_cache=false)
at/root/mysql-5.7.35/storage/innobase/include/page0cur.ic:28720x0000563e03f55a90inbtr_cur_optimistic_insert (flags=0, cursor=0x7f24e569be40, offsets=0x7f24e569bdf0,
heap=0x7f24e569bde8, entry=0x7f248001e420, rec=0x7f24e569bdf8, big_rec=0x7f24e569bde0, n_ext=0,
thr=0x7f2480021828, mtr=0x7f24e569c270) at/root/mysql-5.7.35/storage/innobase/btr/btr0cur.cc:321530x0000563e03e14beainrow_ins_clust_index_entry_low (flags=0, mode=2, index=0x7f2480012290, n_uniq=0,
entry=0x7f248001e420, n_ext=0, thr=0x7f2480021828, dup_chk_only=false)
at/root/mysql-5.7.35/storage/innobase/row/row0ins.cc:261240x0000563e03e16cf7inrow_ins_clust_index_entry (index=0x7f2480012290, entry=0x7f248001e420, thr=0x7f2480021828,
n_ext=0, dup_chk_only=false) at/root/mysql-5.7.35/storage/innobase/row/row0ins.cc:329950x0000563e03e1720binrow_ins_index_entry (index=0x7f2480012290, entry=0x7f248001e420, thr=0x7f2480021828)
at/root/mysql-5.7.35/storage/innobase/row/row0ins.cc:343760x0000563e03e177b4inrow_ins_index_entry_step (node=0x7f2480021588, thr=0x7f2480021828)
at/root/mysql-5.7.35/storage/innobase/row/row0ins.cc:358770x0000563e03e17b47inrow_ins (node=0x7f2480021588, thr=0x7f2480021828)
at/root/mysql-5.7.35/storage/innobase/row/row0ins.cc:372580x0000563e03e17fb3inrow_ins_step (thr=0x7f2480021828) at/root/mysql-5.7.35/storage/innobase/row/row0ins.cc:386190x0000563e03e37a7finrow_insert_for_mysql_using_ins_graph (mysql_rec=0x7f2480010728"\370\001",
prebuilt=0x7f2480020f90) at/root/mysql-5.7.35/storage/innobase/row/row0mysql.cc:1746100x0000563e03e38099inrow_insert_for_mysql (mysql_rec=0x7f2480010728"\370\001", prebuilt=0x7f2480020f90)
at/root/mysql-5.7.35/storage/innobase/row/row0mysql.cc:1866110x0000563e03cce301inha_innobase::write_row (this=0x7f2480010430, record=0x7f2480010728"\370\001")
at/root/mysql-5.7.35/storage/innobase/handler/ha_innodb.cc:7663120x0000563e0326b302inhandler::ha_write_row (this=0x7f2480010430, buf=0x7f2480010728"\370\001")
at/root/mysql-5.7.35/sql/handler.cc:8173130x0000563e03b4a535inwrite_record (thd=0x7f2480000e10, table=0x7f2480020560, info=0x7f24e569d160,
update=0x7f24e569d1e0) at/root/mysql-5.7.35/sql/sql_insert.cc:1895140x0000563e03b472c9inSql_cmd_insert::mysql_insert (this=0x7f2480006df0, thd=0x7f2480000e10,
table_list=0x7f2480006840) at/root/mysql-5.7.35/sql/sql_insert.cc:776150x0000563e03b4e541inSql_cmd_insert::execute (this=0x7f2480006df0, thd=0x7f2480000e10)
at/root/mysql-5.7.35/sql/sql_insert.cc:3142160x0000563e038fec32inmysql_execute_command (thd=0x7f2480000e10, first_level=true)
at/root/mysql-5.7.35/sql/sql_parse.cc:3607170x0000563e03904b72inmysql_parse (thd=0x7f2480000e10, parser_state=0x7f24e569e530)
at/root/mysql-5.7.35/sql/sql_parse.cc:5597180x0000563e038f9964indispatch_command (thd=0x7f2480000e10, com_data=0x7f24e569ede0, command=COM_QUERY)
at/root/mysql-5.7.35/sql/sql_parse.cc:1491190x0000563e038f87e2indo_command (thd=0x7f2480000e10) at/root/mysql-5.7.35/sql/sql_parse.cc:1032200x0000563e03a41940inhandle_connection (arg=0x563e0756a440)
at/root/mysql-5.7.35/sql/conn_handler/connection_handler_per_thread.cc:313210x0000563e041844c7inpfs_spawn_thread (arg=0x563e073cae70) at/root/mysql-5.7.35/storage/perfschema/pfs.cc:2197220x00007f24eb2e2609instart_thread (arg=<optimizedout>) atpthread_create.c:477
相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
打赏
0
0
0
0
25
分享
相关文章
MySQL底层概述—2.InnoDB磁盘结构
InnoDB磁盘结构主要包括表空间(Tablespaces)、数据字典(Data Dictionary)、双写缓冲区(Double Write Buffer)、重做日志(redo log)和撤销日志(undo log)。其中,表空间分为系统、独立、通用、Undo及临时表空间,分别用于存储不同类型的数据。数据字典从MySQL 8.0起不再依赖.frm文件,转而使用InnoDB引擎存储,支持事务原子性DDL操作。
156 100
MySQL底层概述—2.InnoDB磁盘结构
MySQL底层概述—10.InnoDB锁机制
本文介绍了:锁概述、锁分类、全局锁实战、表级锁(偏读)实战、行级锁升级表级锁实战、间隙锁实战、临键锁实战、幻读演示和解决、行级锁(偏写)优化建议、乐观锁实战、行锁原理分析、死锁与解决方案
MySQL底层概述—10.InnoDB锁机制
MySQL底层概述—5.InnoDB参数优化
本文介绍了MySQL数据库中与内存、日志和IO线程相关的参数优化,旨在提升数据库性能。主要内容包括: 1. 内存相关参数优化:缓冲池内存大小配置、配置多个Buffer Pool实例、Chunk大小配置、InnoDB缓存性能评估、Page管理相关参数、Change Buffer相关参数优化。 2. 日志相关参数优化:日志缓冲区配置、日志文件参数优化。 3. IO线程相关参数优化: 查询缓存参数、脏页刷盘参数、LRU链表参数、脏页刷盘相关参数。
MySQL底层概述—5.InnoDB参数优化
MySQL底层概述—4.InnoDB数据文件
本文介绍了InnoDB表空间文件结构及其组成部分,包括表空间、段、区、页和行。表空间是最高逻辑层,包含多个段;段由若干个区组成,每个区包含64个连续的页,页用于存储多条行记录。文章还详细解析了Page结构,分为通用部分(文件头与文件尾)、数据记录部分和页目录部分。此外,文中探讨了行记录格式,包括四种行格式(Redundant、Compact、Dynamic和Compressed),重点介绍了Compact行记录格式及其溢出机制。最后,文章解释了不同行格式的特点及应用场景,帮助理解InnoDB存储引擎的工作原理。
MySQL底层概述—4.InnoDB数据文件
MySQL底层概述—3.InnoDB线程模型
InnoDB存储引擎采用多线程模型,包含多个后台线程以处理不同任务。主要线程包括:IO Thread负责读写数据页和日志;Purge Thread回收已提交事务的undo日志;Page Cleaner Thread刷新脏页并清理redo日志;Master Thread调度其他线程,定时刷新脏页、回收undo日志、写入redo日志和合并写缓冲。各线程协同工作,确保数据一致性和高效性能。
MySQL底层概述—3.InnoDB线程模型
Docker Compose V2 安装常用数据库MySQL+Mongo
以上内容涵盖了使用 Docker Compose 安装和管理 MySQL 和 MongoDB 的详细步骤,希望对您有所帮助。
80 42
【深入了解MySQL】优化查询性能与数据库设计的深度总结
本文详细介绍了MySQL查询优化和数据库设计技巧,涵盖基础优化、高级技巧及性能监控。
211 0
数据库传奇:MySQL创世之父的两千金My、Maria
《数据库传奇:MySQL创世之父的两千金My、Maria》介绍了MySQL的发展历程及其分支MariaDB。MySQL由Michael Widenius等人于1994年创建,现归Oracle所有,广泛应用于阿里巴巴、腾讯等企业。2009年,Widenius因担心Oracle收购影响MySQL的开源性,创建了MariaDB,提供额外功能和改进。维基百科、Google等已逐步替换为MariaDB,以确保更好的性能和社区支持。掌握MariaDB作为备用方案,对未来发展至关重要。
72 3
MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!
《MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!》介绍了MySQL中的三种关键日志:二进制日志(Binary Log)、重做日志(Redo Log)和撤销日志(Undo Log)。这些日志确保了数据库的ACID特性,即原子性、一致性、隔离性和持久性。Redo Log记录数据页的物理修改,保证事务持久性;Undo Log记录事务的逆操作,支持回滚和多版本并发控制(MVCC)。文章还详细对比了InnoDB和MyISAM存储引擎在事务支持、锁定机制、并发性等方面的差异,强调了InnoDB在高并发和事务处理中的优势。通过这些机制,MySQL能够在事务执行、崩溃和恢复过程中保持
118 3
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等