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

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS PostgreSQL,高可用系列 2核4GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介: 研究和学习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
相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。 &nbsp; 相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情:&nbsp;https://www.aliyun.com/product/rds/mysql&nbsp;
相关文章
|
5月前
|
存储 网络协议 关系型数据库
MySQL8.4创建keyring给InnoDB表进行静态数据加密
MySQL8.4创建keyring给InnoDB表进行静态数据加密
138 1
|
3月前
|
SQL 关系型数据库 MySQL
MySQL 常用函数
我们这次全面梳理 MySQL 中的常用函数,涵盖 聚合函数、字符串函数、日期时间函数、数学函数 和 控制流函数 等五大类。每类函数均配有语法说明与实用示例,帮助读者提升数据处理能力,如统计分析、文本处理、日期计算、条件判断等。文章结尾提供了丰富的实战练习,帮助读者巩固和应用函数技巧,是进阶 SQL 编程与数据分析的实用工具手册。
263 2
|
4月前
|
存储 SQL 缓存
mysql数据引擎有哪些
MySQL 提供了多种存储引擎,每种引擎都有其独特的特点和适用场景。以下是一些常见的 MySQL 存储引擎及其特点:
131 0
|
9月前
|
存储 缓存 关系型数据库
【MySQL进阶篇】存储引擎(MySQL体系结构、InnoDB、MyISAM、Memory区别及特点、存储引擎的选择方案)
MySQL的存储引擎是其核心组件之一,负责数据的存储、索引和检索。不同的存储引擎具有不同的功能和特性,可以根据业务需求 选择合适的引擎。本文详细介绍了MySQL体系结构、InnoDB、MyISAM、Memory区别及特点、存储引擎的选择方案。
1606 57
【MySQL进阶篇】存储引擎(MySQL体系结构、InnoDB、MyISAM、Memory区别及特点、存储引擎的选择方案)
|
6月前
|
SQL 关系型数据库 MySQL
【YashanDB知识库】MySQL field 函数的改写方法
【YashanDB知识库】MySQL field 函数的改写方法
|
5月前
|
SQL 缓存 关系型数据库
使用温InnoDB缓冲池启动MySQL测试
使用温InnoDB缓冲池启动MySQL测试
100 0
|
6月前
|
SQL 关系型数据库 MySQL
【YashanDB知识库】MySQL field 函数的改写方法
本文来自YashanDB官网,介绍将MySQL的FIELD函数改写到YashanDB的方法。MySQL中,FIELD函数用于自定义排序;而在YashanDB中,可使用DECODE或CASE语句实现类似功能。示例展示对表`t1`按指定顺序排序的过程,提供两种改写方式,结果均符合预期。
|
8月前
|
SQL 关系型数据库 MySQL
Mysql-常用函数及其用法总结
以上列举了MySQL中一些常用的函数及其用法。这些函数在日常的数据库操作中非常实用,能够简化数据查询和处理过程,提高开发效率。掌握这些函数的使用方法,可以更高效地处理和分析数据。
227 19
|
9月前
|
存储 关系型数据库 MySQL
【MYSQL】 ——索引(B树B+树)、设计栈
索引的特点,使用场景,操作,底层结构,B树B+树,MYSQL设计栈
|
3月前
|
人工智能 运维 关系型数据库
数据库运维:mysql 数据库迁移方法-mysqldump
本文介绍了MySQL数据库迁移的方法与技巧,重点探讨了数据量大小对迁移方式的影响。对于10GB以下的小型数据库,推荐使用mysqldump进行逻辑导出和source导入;10GB以上可考虑mydumper与myloader工具;100GB以上则建议物理迁移。文中还提供了统计数据库及表空间大小的SQL语句,并讲解了如何使用mysqldump导出存储过程、函数和数据结构。通过结合实际应用场景选择合适的工具与方法,可实现高效的数据迁移。
643 1

推荐镜像

更多