MySQL Update执行流程解读

mysql update语句的执行流程 update tb_student A set A.age=‘19’ where A.name=’ 张三 '; 阅读详情
  • GreatSQL社区原创内容未经授权不得随意使用,转载请联系小编并注明来源。

一、update跟踪执行配置

使用内部程序堆栈跟踪工具path_viewer,跟踪mysql update 一行数据的执行过程,配置执行脚本:call_update.sh

DROP DATABASE IF EXISTS d1;
CREATE DATABASE d1;
use d1;
drop table if exists test;
CREATE TABLE test (c0 int NOT NULL AUTO_INCREMENT,c1 date DEFAULT NULL,c2 time DEFAULT NULL,
  c3 datetime DEFAULT NULL,
  c4 year DEFAULT NULL,
  c5 int DEFAULT NULL,
  c6 decimal(10,6) DEFAULT NULL,
  c7 double DEFAULT NULL,
  c8 float DEFAULT NULL,
  c9 varchar(255) DEFAULT NULL,
  PRIMARY KEY (c0)
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

INSERT INTO test VALUES ('1', '2021-04-26', '15:36:37', NULL, '2021', NULL, '6.000000', '7.1', '118.169', 'a8.168111');
INSERT INTO test VALUES ('2', '2021-04-28', '15:36:37', '2021-04-27 15:36:41', '2021', '6', '7877.126000', '8.1', '119.187', 'a9.16');
INSERT INTO test VALUES ('3', '2021-04-29', '15:36:37', '2021-04-27 15:36:41', '2021', '6', '7877.126890', '8.1', '119.187', 'a9.1682');
INSERT INTO test VALUES ('4', '2021-04-30', '15:36:37', '2021-04-27 15:36:41', '2021', '6', '7877.126890', '8.1', '119.187', 'a9.168333');
EOF

sleep 1

mysql -h127.0.0.1 -P3300 -uroot <<EOF 
use d1;

\! ./util/start_trace.sh

update test set c7=10.1 where c0=1;

\! ./util/end_trace.sh
EOF

# analyse the data
./util/seperate.sh $TOPIC 10000 5
~                                                    

执行后,生成执行结果:

path_viewer/call_update$ ls
362688_5.txt  362689.dat    362690.inf    362692_5.txt  362699.dat    362706.inf    362717_L.txt  mark.txt
362688.dat    362689.inf    362691_5.txt  362692.dat    362699.inf    362717_5.txt  362717_M.txt  TDATA.trc
362688.inf    362690_5.txt  362691.dat    362692.inf    362706_5.txt  362717.dat    362717_S.txt  THREADS.inf
362689_5.txt  362690.dat    362691.inf    362699_5.txt  362706.dat    362717.inf    FUNC_DEF

查看SQL执行的函数调用过程362717_5.txt

 > my_net_set_read_timeout(NET*, unsigned int)
        > vio_timeout(Vio*, unsigned int, int)
            > vio_socket_timeout(Vio*, unsigned int, bool)
            < vio_socket_timeout(Vio*, unsigned int, bool)
        < vio_timeout(Vio*, unsigned int, int)
    < my_net_set_read_timeout(NET*, unsigned int)
    > dispatch_command(THD*, COM_DATA const*, enum_server_command)
        > PROFILING::start_new_query(char const*)
        < PROFILING::start_new_query(char const*)
        > inline_mysql_refine_statement(PSI_statement_locker*, unsigned int)
            > pfs_refine_statement_v2(PSI_statement_locker*, unsigned int)
                > find_statement_class(unsigned int)
                < find_statement_class(unsigned int)
            < pfs_refine_statement_v2(PSI_statement_locker*, unsigned int)
        < inline_mysql_refine_statement(PSI_statement_locker*, unsigned int)
        > THD::set_command(enum_server_command)
            > pfs_set_thread_command_vc(int)
            < pfs_set_thread_command_vc(int)
        < THD::set_command(enum_server_command)
        > THD::clear_slow_extended()
            > inline_mysql_mutex_unlock(mysql_mutex_t*, char const*, unsigned int)
                > my_mutex_unlock(my_mutex_t*)
                    > native_mutex_unlock(pthread_mutex_t*)
                    < native_mutex_unlock(pthread_mutex_t*)
                < my_mutex_unlock(my_mutex_t*)
            < inline_mysql_mutex_unlock(mysql_mutex_t*, char const*, unsigned int)
        < THD::clear_slow_extended()
.................................

                   < MYSQLparse(THD*, Parse_tree_root**)
                    > LEX::make_sql_cmd(Parse_tree_root*)
                        > PT_update::make_cmd(THD*) 
                            > Parse_context::Parse_context(THD*, Query_block*)
                            < Parse_context::Parse_context(THD*, Query_block*)
                            > bool (anonymous namespace)::contextualize_safe<Parse_context, PT_with_clause*>(Parse_context*, PT_with_clause*)
                            < bool (anonymous namespace)::contextualize_safe<Parse_context, PT_with_clause*>(Parse_context*, PT_with_clause*)
                            > PT_table_factor_table_ident::contextualize(Parse_context*)
                                > Query_block::add_table_to_list(THD*, Table_ident*, char const*, unsigned long, thr_lock_type, enum_mdl_type, List<Index_hint>*, List<String>*, MYSQL_LEX_STRING*, Parse_context*)
                                    > check_table_name(char const*, unsigned long)
                                    < check_table_name(char const*, unsigned long)
                                    > memdup_root(MEM_ROOT*, void const*, unsigned long)
.................................
             > Sql_cmd_dml::execute(THD*)  # 执行DML
                    > is_timer_applicable_to_statement(THD*)
                    < is_timer_applicable_to_statement(THD*)
                    > THD::push_internal_handler(Internal_error_handler*)
                    < THD::push_internal_handler(Internal_error_handler*)
                    > Sql_cmd_dml::prepare(THD*)
                        > Sql_cmd_update::precheck(THD*)
                            > check_one_table_access(THD*, unsigned long, TABLE_LIST*)
                                > check_single_table_access(THD*, unsigned long, TABLE_LIST*, bool)
                                    > check_access(THD*, unsigned long, char const*, unsigned long*, GRANT_INTERNAL_INFO*, bool, bool)
                                        > get_cached_schema_access(GRANT_INTERNAL_INFO*, char const*)
                                            > ACL_internal_schema_registry::lookup(char const*)
                                            < ACL_internal_schema_registry::lookup(char const*)
.................................
                            < THD::is_dml_gtid_compatible(bool, bool, bool)
                        < THD::decide_logging_format(TABLE_LIST*)
                    < lock_tables(THD*, TABLE_LIST*, unsigned int, unsigned int)
                    > Sql_cmd_update::execute_inner(THD*)
                        > Sql_cmd_update::update_single_table(THD*)
                            > Query_expression::set_limit(THD*, Query_block*)
                                > Query_block::get_offset(THD*)
                                < Query_block::get_offset(THD*)
                                > Query_block::get_limit(THD*)
                                < Query_block::get_limit(THD*)
                            < Query_expression::set_limit(THD*, Query_block*)
                            > COPY_INFO::get_function_default_columns(TABLE*)
                                > allocate_column_bitmap(TABLE*, MY_BITMAP**)
                                    > multi_alloc_root(MEM_ROOT*, ...)
                                    < multi_alloc_root(MEM_ROOT*, ...)
                                < allocate_column_bitmap(TABLE*, MY_BITMAP**)
                                > bitmap_is_clear_all(MY_BITMAP const*)
                                < bitmap_is_clear_all(MY_BITMAP const*)
.................................
                            > handler::ha_fast_update(THD*, mem_root_deque<Item*>&, mem_root_deque<Item*>&, Item*)
                            < handler::ha_fast_update(THD*, mem_root_deque<Item*>&, mem_root_deque<Item*>&, Item*)
                            > IndexRangeScanIterator::Read()
                                > QUICK_RANGE_SELECT::get_next()
                                    > handler::ha_multi_range_read_next(char**)
                                        > ha_innobase::multi_range_read_next(char**)
> DsMrr_impl::dsmrr_next(char**)
                                                > handler::multi_range_read_next(char**)
                                                    > quick_range_seq_next(void*, KEY_MULTI_RANGE*)
                                                    < quick_range_seq_next(void*, KEY_MULTI_RANGE*)
                                                    > ha_innobase::read_range_first(key_range const*, key_range const*, bool, bool)
                                                        > handler::read_range_first(key_range const*, key_range const*, bool, bool)
.................................

                            > handler::ha_update_row(unsigned char const*, unsigned char*)
                                > handler::mark_trx_read_write()
                                < handler::mark_trx_read_write()
                                > pfs_start_table_io_wait_v1(PSI_table_locker_state*, PSI_table*, PSI_table_io_operation, unsigned int, char const*, unsigned int)
                                < pfs_start_table_io_wait_v1(PSI_table_locker_state*, PSI_table*, PSI_table_io_operation, unsigned int, char const*, unsigned int)
                                > ha_innobase::update_row(unsigned char const*, unsigned char*)
                                    > handler::ha_statistic_increment(unsigned long long System_status_var::*) const
                                    < handler::ha_statistic_increment(unsigned long long System_status_var::*) const
                                    > row_get_prebuilt_update_vector(row_prebuilt_t*)
                                        > row_create_update_node_for_mysql(dict_table_t*, mem_block_info_t*)
                                            > upd_node_create(mem_block_info_t*)
                                                > mem_heap_zalloc(mem_block_info_t*, unsigned long)
                                                    > mem_heap_alloc(mem_block_info_t*, unsigned long)
                                                        > mem_block_get_len(mem_block_info_t*)
                                                        < mem_block_get_len(mem_block_info_t*)
                                                        > mem_block_get_free(mem_block_info_t*)
                                                        < mem_block_get_free(mem_block_info_t*)
                                                        > mem_block_get_free(mem_block_info_t*)
                                                        < mem_block_get_free(mem_block_info_t*)
                                                        > mem_block_set_free(mem_block_info_t*, unsigned long)
                                                        < mem_block_set_free(mem_block_info_t*, unsigned long)
                                                    < mem_heap_alloc(mem_block_info_t*, unsigned long)
                                                < mem_heap_zalloc(mem_block_info_t*, unsigned long)
                                                > mem_heap_create_func(unsigned long, unsigned long)
.................................

                                                > __gnu_cxx::__exchange_and_add(int volatile*, int)
                                                < __gnu_cxx::__exchange_and_add(int volatile*, int)
                                            < __gnu_cxx::__exchange_and_add_dispatch(int*, int)
                                        < QUICK_RANGE_SELECT::~QUICK_RANGE_SELECT()
                                    < QUICK_RANGE_SELECT::~QUICK_RANGE_SELECT()
                                < QEP_shared_owner::qs_cleanup()
                            < QEP_TAB::cleanup()
                        < Sql_cmd_update::update_single_table(THD*)
                    < Sql_cmd_update::execute_inner(THD*)
                    > THD::pop_internal_handler()
                    < THD::pop_internal_handler()
                    > Query_expression::cleanup(THD*, bool)
                        > Query_block::cleanup(THD*, bool)
                        < Query_block::cleanup(THD*, bool)
                    < Query_expression::cleanup(THD*, bool)

二、执行分析

  • 主要过程函数
    do_command(THD*)      --从连接中读取命令
    dispatch_sql_command   --分发命令
    THD::sql_parser()      --SQL引擎层,词法语法分析
    parse_sql       --SQL转换为AST语句
      LEX::make_sql_cmd(Parse_tree_root*)  --解析树翻译成AST语法树
       PT_update::make_cmd(THD*)   --更新树节点翻译成AST语法树
    

mysql_execute_command --命令执行 Sql_cmd_dml::execute Sql_cmd_dml::prepare(THD) --引用消解 Sql_cmd_update::precheck(THD) --更新语句实际执行的引用消解

Sql_cmd_update::execute_inner(THD) --SQL引擎层,调用存储引擎接口执行 Sql_cmd_update::update_single_table(THD) optimize_cond --执行优化器优化路径 handler::ha_fast_update ha_innobase::update_row --innodb更新buffer pool 中table 的row trans_commit_stmt(THD*, bool)


- innoDB关键更新执行过程

ha_innobase::update_row: row_get_prebuilt_update_vector calc_row_difference row_update_for_mysql row_upd_step row_upd --执行更新 btr_pcur_t::restore_position rec_get_offsets_func btr_cur_update_in_place btr_cur_upd_lock_and_undo trx_undo_report_row_operation trx_undo_create trx_undo_seg_create _fil_io Fil_shard::do_io pfs_os_aio_func mtr_t::Command::execute log_buffer_reserve mtr_t::Command::add_dirty_blocks_to_flush_list ---脏数据快准备刷入磁盘 trx_undo_page_report_modify row_upd_rec_sys_fields row_upd_rec_in_place btr_cur_update_in_place_log

```

更新过程描述:

InnoDB 存储引擎,当更新一条数据时,会先更新 buffer pool 中的数据,Master Thread 刷新缓冲池中的脏页数据到磁盘中;更新一条记录前,会先生成一条undolog,记录更新操作,再生成redolog;事务提交时,将事务生成的redolog刷入磁盘。

三、执行总结

update执行流程

  • 1.执行语句连接数据库
  • 2.分析器通过词法、语法分析知道这是一条更新语句
  • 3.优化器确定执行路径
  • 4.执行器具体执行,找到这一行,更新数据,然后通过Inodb存储具体更新操作
  • 5.InnoDB 存储引擎更新内存数据后写入磁盘,过程中会更新各个日志文件binlog、undolog、redolog

Enjoy GreatSQL :)

本文由博客一文多发平台 OpenWrite 发布!

MySQL执行计划解读 MySQL 执行计划(Execution Plan)是 MySQL 优化器为一条 SQL 查询生成的**详细执行方案**,它描述了数据库将如何执行这条查询,包括:将访问哪些表、使用什么索引、如何连接多个表、扫描多少数据行等关键信息。简单来说,执行计划就像查询的 “路线图”—— 优化器根据表结构、索引、数据量、SQL 语法等因素,计算出它认为 “最高效” 的执行方式,并以结构化表格的形式展示出来。 阅读详情

相关推荐

【MySQL】SQL执行计划分析

MySQL EXPLAIN命令是查询性能优化不可缺少的一部分,该文主要讲解explain命令的使用及相关参数说明。

多多说happy的博客 2万+

关于 MySQL 中 Update 使用

本文介绍了 MySQL 中 Update 命令的基本语法以及一些特殊的用法,包括多表联合更新和使用子查询。通过本文的学习,您应该能够使用 Update 命令来更新表格中的记录,并根据需要修改它们的值。总体而言,Update 命令是 MySQL 中非常常用的一种命令,掌握它对于进行数据更新操作是非常重要的。

小羊的博客 7万+

OceanBase SQL 执行计划解读(一)──基础概念

本文分享 OceanBase SQL 执行计划解读经验。 对于熟悉 ORACLE 或 MySQL 的朋友,初次看 OceanBase 的执行计划,会觉得难以理解和接受。相反,只懂一些数据库理论但没有接触过其他数据库的人看 OceanBase 的执行计划反而更容易接受并掌握。这种感觉可能就像武侠小说里说的,得先忘记以前的功夫才能学会新的绝世武功 ????️。等看习惯了OceanBase的SQL执行计划后,自然就适应并体会到自研SQL引擎为何能兼具 OLTP 和 OLAP 两种场景的能力。 执行计划的概念

OceanBase分布式数据库的博客 7934

mysql 修改_MySQL更新(修改、查询)

更新 updatesetwhere…#修改 update(修改)info set sex=‘1’where code=‘p003’单列 update info set sex=‘0’nation='n004'birthday='1999-9-9'where code='p001' update car set price=price*0.9 where price>30 upd...

weixin_39607710的博客 330

按照autoware.universe官方从零搭建自己的自动导航小车(三)(续)

本文介绍了在Autoware框架下完善自定义传感器套件描述包的详细过程。主要内容包括:1)创建传感器描述包tinyplc_sensor_kit_description,包含YAML标定文件和URDF模型;2)配置传感器与车辆基座的相对位姿,实现sensor_kit.xacro和sensors.xacro宏文件;3)更新sensor_kit.launch.xml文件以集成激光雷达和GNSS/IMU驱动。通过xacro验证URDF模型正确性后,下一步计划接入Helios16激光雷达数据并在Rviz2中验证点云显

qq_45335326的博客 1273

SoIC、CoWoS、InFO一次讲透:从2D/2.5D/3D看懂先进封装

先进封装是后摩尔时代提升芯片性能的关键路径,但面对SoIC、CoWoS、InFO这些名词,很多人容易混淆。理解它们,需从最基本的2D、2.5D、3D封装概念入手:2D是传统平房,2.5D通过硅中介层实现高密度互连,3D则让芯片直接堆叠。CoWoS作为2.5D中介层封装,已成为AI芯片与HBM高带宽存储集成的行业标准;SoIC通过铜-铜混合键合实现真正的3D堆叠,为逻辑与缓存提供极致带宽;InFO以扇出型封装兼顾成本与集成度,广泛用于移动SoC。在系统级封装(SiP)和CPO共封装光学等前沿趋势中,这些技术往

weixin_42388898的博客 311

一条Update语句的执行过程是怎样的?

通过本文主要了解Sql执行流程,包括两个问题:MySQL的一条Select语句是怎么运行的MySQL的一条Update语句是怎么运行的先看第一个问题,这里做个简单描述 ,因为我们着重还是看UpdateMySQL执行一条Select语句是怎么运行的?这个问题大家在面试的时候大家都背过类似的题,而且网上也有很多答案,这里分享一个大致流程介绍,关于下图的介绍来自这里执行一条 select 语句,期间发生了什么?。​连接器:建立连接,管理连接、校验用户身份;

go go go 839

退火朗之万动力学采样

退火朗之万动力学采样(Simulated Annealing Langevin Dynamics Sampling)结合了退火技术和朗之万动力学,是一种用于分子模拟和统计物理中的计算方法。这种方法可以帮助系统从局部最小值中逃逸,以找到全局最小值或进行有效的配置空间探索。

weixin_39699362的博客 1949

shell操作mysql

通过 shell 操作 mysql ,有一些需要注意的点。

tlqwanttolearnit的博客 4360

单相PWM整流器四象限运行原理

简述单相PWM整流器四象限运行原理。

m0_75208156的博客 8301

从零到一:RJ71EN71 ModbusTCP配置的避坑指南与实战技巧

本文详细解析三菱RJ71EN71模块的ModbusTCP配置全流程,涵盖GX Works3参数设置、地址映射、通信调试等核心环节。针对工业环境中常见的IP冲突、软元件分配错误、通信超时等高频问题提供实战解决方案,帮助工程师快速构建高可靠性通信网络,避免项目延期风险。

zzz56的博客 331

MySQL中 SELECT/UPDATE 语句执行流程?

1. 连接器连接器主要和身份认证和权限相关的功能相关,就好比一个级别很高的门卫一样。主要负责用户登录数据库,进行用户的身份认证,包括校验账户密码,权限等操作,如果用户账户密码已通过,连接器会到权限表中查询该用户的所有权限,之后在这个连接里的权限逻辑判断都是会依赖此时读取到的权限数据,也就是说,后续只要这个连接不断开,即使管理员修改了该用户的权限,该用户也是不受影响的。概括一句话:连接器就像数据库的“门卫”,负责验证用户身份和权限,并在连接期间保持这些权限不变。2. 查询缓存(MySQL8.0版本后移除。

asdfq13435009912的博客 1104

海康工业相机排雷笔记02-像素格式解析

工业相机使用过程记录 02-像素格式解析 通过将相机输出图像裸数据raw格式直接存图查看 一、黑白/Mono 直接使用相机测试图像存图: 图像中各部分灰度分别为:0、36、73、109、146、182、219、255,以灰度73列为例 (1)Mono 8 该列图像数据为十六进制49,十进制为73,那么Mono 8就是每个像素点占8bit,依次排列。 (2)Mono 10 该列图像数据为十六进制2401,由于相机均为小端数据,实际数据应解析为0124,十进制为292=73*4,那么Mono 10格式为每

yonghuming_66的博客 8359

你确定你读懂了 MySQL 执行计划吗?

MySQL 执行计划(execution plan,也叫查询计划或者解释计划)是服务器执行 SQL 语句的具体步骤。本文通过具体案例详细介绍了如何使用各种 EXPLAIN 语句获取 MySQL 预期执行计划和实际执行计划,并且深入分析了结果中的每个字段的含义,包括访问谓词与过滤谓词的区别。

Tony.Dong的专栏 6139

FreeRTOS深入教程(任务创建的深入和任务调度机制分析)

本篇文章将带大家深入学习任务的创建和分析任务调度的机制。本篇文章深入的讲解了任务创建的内部实现和任务调度的源代码分析和实现,学习这篇文章有助于更深入的学习FreeRTOS的源码。

m0_49476241的博客 6391

SerDes系列之 SSC扩频时钟技术

扩频时钟,又称展频(SSC-Spread Spectrum Clocking),当前PCIE、DDR、USB等几乎所有的高速接口都支持SSC的功能。电子工程师在日常的电气测试中经常与之接触,在电磁传导和辐射发射验证过程中,经常需要使用到芯片的SSC功能,它的物理表现形式,就是信号的比特率会在一个很小的范围内浮动,多见于周期性变化的时钟信号。

一只豌豆象的博客 3442

居然可以这样聊MySQL的数据更新流程(update)

MySQL数据更新流程

健身变秃,coding变强 2362

C# WinForm 基于DirectShow.dll编写的程序,可边预览边保存视频,音频和图片

基于微软的DirectShow.dll的二次开发1.自动识别连接的摄像头跟麦克风且可以对其进行选择(默认选中第一个)2.可录制wmv和avi两种格式的视频并且都带有音频,avi可以录制的分辨率和帧数进行选择,wmv默认进行了淸晰度优化如不喜欢可去除代码中有相关提示3.可在预览点开之后进行拍照,也可边录制视频边拍照4.添加了视频和音频的压缩功能(酌情使用)这次二次开发发现C#对DirectShow的相关信息太少,这次做完也不敢藏私共享出来,还望大家指正

深入解析mysql的update语句执行

注:本博客参照b站视频。

m0_74075279的博客 1000

Statistics and Machine Learning Toolbox

Statistics and Machine Learning Toolbox(带书签),MATLAB统计学习工具

ET2012新版免狗免安装绿色软件

ET2012新版免狗免安祖昂绿色软件。,新界面,新视觉,

MySQL EXPLAIN 完全解读

MySQL EXPLAIN 完全解读 Explain 命令在解决数据库性能上是第一推荐使用命令,大部分的性能问题可以通过此命令来简单的解决,Explain 可以用来查看 SQL 语句的执行效 果,可以帮助选择更好的索引和优化查询语句,写出更好的优化语句。 ‍ 命令使用 explain 可用来分析 SQL 的执行计划,格式如下: {EXPLAIN | DESCRIBE | DESC} tbl_name [col_name | wild] {EXPLAIN | DESCRIBE | DESC}

追风少年仍在追风~ 3540

霍尼韦尔SoftMaster使用说明

霍尼韦尔SoftMaster使用说明

MySql 执行计划

执行计划(execution plan,也叫查询计划或者解释计划)是 MySQL 服务器执行 SQL 语句的具体步骤。例如,通过索引还是全表扫描访问表中的数据,连接查询的实现方式和连接的顺序,分组和排序操作的实现方式等。负责生成执行计划的组件就是优化器,优化器利用表结构、字段、索引、查询条件、数据库的统计信息和配置参数决定 SQL 语句的最佳执行方式。如果想要解决慢查询的性能问题,首先应该查看它的执行计划。

TMesh的博客 1172

MySQL update语句带子查询的优化探寻

可见 MySQL 5.7 对 update 语句带 IN 子查询的优化是比较差劲的,即使条件涉及的字段均有索引,优化器也会将语句优化成 EXISTS 条件,导致外表全表扫描;这样的SQL咋一看,record.uuid、bill.apply_id 均有索引,似乎并没有什么问题,但实际上线后(record表千万数量级)却会执行超时(5秒)。执行计划咋一看有走索引,实际上从key和扫描行数rows可看出走了全表扫描,导致执行时长需0.12秒。结果如下,表现一致,仍就走了全表扫描。确实是走了全表扫描。

sc35262的博客 566

MySQL8.0之执行计划

文章目录MySQL8.0.17之执行计划一、SQL执行过程1.1 SQL语句内部执行过程1.2 SQL语句执行顺序二、执行计划解读2.1如何查看SQL语句执行计划2.2 TRADITIONAL格式输出说明2.2.1 id2.2.2 select_type2.2.3 table2.2.4 partitions2.2.5 type2.2.6 possible_keys2.2.7 key2.2.8 ke...

雪辉博客 1864

MySQL explain执行计划解读

《MySQL explain执行计划解读》首发橙寂博客转发请加此提示 MySQL explain执行计划解读 本文我们主要介绍了MySQL性能分析以及explain的使用,包括:组合索引、慢查询分析、MYISAM和INNODB的锁定、MYSQL的事务配置项等,希望能够对您有所帮助。 **1.使用explain语句去查看分析结果 ** 如explain select * from test1 whe...

牧码人博客@luckyhe.com 287

【MySQL】获取执行计划

执行计划(execution plan,也叫查询计划或者解释计划)是 MySQL 服务器执行 SQL 语句的具体步骤。例如,通过索引还是全表扫描访问表中的数据,连接查询的实现方式和连接的顺序,分组和排序操作的实现方式等。 负责生成执行计划的组件就是优化器,优化器利用表结构、字段、索引、查询条件、数据库的统计信息和配置参数决定 SQL 语句的最佳执行方式。如果想要解决慢查询的性能问题,首先应该查看它的执行计划。 获取执行计划 MySQL 提供了 EXPLAIN 语句,用于获取 SQL 语句的执行计划。该语句的

a6458360的博客 856

MySQL Online DDL原理解读

MySQL原生Online DDL是MySQL数据库提供的一项功能,它允许在不中断数据库服务的情况下执行数据定义语言(DDL)操作。

码到三十五 1万+
上一篇: MySQL B+树索引和哈希索引的区别
下一篇: MySQL 常见索引类型介绍
GreatSQL社区
博客等级 码龄5年 1210粉丝 390原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值