股票代码
301208
在MySQL中，update语句用于修改已经存在的数据记录。那么，每次使用update语句都会修改数据吗？针对这一大家关注的问题，今天，我们将深入探讨这个问题，帮助你更好地理解MySQL的update操作。
问题描述
假设我们有这样一张表，且包含一条记录：
CREATE TABLE `mytest` (
`id` int(11) NOT NULL,
`c1` int(11) DEFAULT NULL,
`c2` int(11) DEFAULT NULL,
`c3` int(11) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `c1` (`c1`),
KEY `c2` (`c2`)
包含记录：
+----+------+------+------+
| id | c1 | c2 | c3 |
+----+------+------+------+
| 1 | 11 | 12 | 13 |
这个表实际上包含3个索引：
主键索引（且值包含一个block）
索引c1（且值包含一个block）
索引c2（且值包含一个block）
那么我们考虑如下的语句：
A: update mytest set c1=11,c2=12,c3=13 where id=1（c1\c2\c3字段都不更改）
B: update mytest set c1=11,c2=12,c3=14 where id=1（c1\c2字段不更改）
C: update mytest set c1=12,c2=12,c3=14 where id=1（c2字段不更改）
那么问题如下：
A 场景下各个索引的值是否更改，也就是实际的各个索引block是否更改。
B 场景下索引c1和索引c2的数据是否更改，也就是实际的索引c1和索引c2的block是否更改。
C 场景下索引c2的数据是否更改，也就是实际索引c2的block是否更改。
大概的执行方式和流程
对于update语句来讲，函数mysql_update对修改流程大概如下：
扫描数据，获取数据(rr_sequential)，存储mysql格式的数据到record[0]中，其表示大概如下：
field1 | field2 | … | fieldN
每个field都包含一个指向实际数据的指针。
保存获取的mysql格式的数据到record[1]中，然后使用语法解析后的信息填充获取的record[0]中的数据（fill_record_n_invoke_before_triggers->fill_record），这里就是使用 -> c1=*,c2=*,c3=* 填充数据，需要填充的数据和字段实际上保存在两个List
$$.column_list->push_back($1.column) ||
$$.value_list->push_back($1.value))
（左右滑动查看更多）
下面使用语句update mytest set c1=11,c2=12,c3=13 where id=1来debug一下这个两个list，我们断点放到fill_record_n_invoke_before_triggers就可以了。
(gdb) p fields
$67 = (List<Item> &) @0x7fff30005da8: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x7fff300067f8, last = 0x7fff30006af8, elements = 3}, <No data fields>}
(gdb) p ((Item_field *)(fields->first->info)).field_name
$68 = 0x7fff309316d4 "c1"
(gdb) p ((Item_field *)(fields->first->next->info)).field_name
$69 = 0x7fff309316d7 "c2"
(gdb) p ((Item_field *)(fields->first->next->next->info)).field_name
$70 = 0x7fff309316da "c3"
(gdb) p values
$73 = (List<Item> &) @0x7fff30006e38: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x7fff30006808, last = 0x7fff30006b08, elements = 3}, <No data fields>}
(gdb) p ((Item_int*)(values->first->info)).value
$74 = 11
(gdb) p ((Item_int*)(values->first->next->info)).value
$75 = 12
(gdb) p ((Item_int*)(values->first->next->next->info)).value
$76 = 13
（左右滑动查看更多）
这样修改后record[0]中需要修改的字段的值就变为了本次update语句中的值。
过滤点1，比对record[0]和record[1] 中数据是否有差异，如果完全相同则不触发update，这里也就对应我们的场景A，因为前后记录的值一模一样，因此是不会做任何数据更改的，这里直接跳过了
到这里肯定是要修改数据的，因此对比record[0]和record[1]的记录，将需要修改的字段的值和字段号放入到数组m_prebuilt->upd_node->update中（calc_row_difference），其中主要是需要修改的new值和需要修改的field_no比对方式为：
1.长度是否更改了(len)
2.实际值更改了(memcmp比对结果)
确认修改的字段是否包含了二级索引。因为前面已经统计出来了需要更改的字段（row_upd的开头），那么这里对比的方式如下：
1.如果为delete语句显然肯定包含所有的二级索引
2.如果为update语句，根据前面数组中字段的号和字典中字段是否排序进行比对，因为二级索引的字段一定是排序的
如果两个条件都不满足，这说明没有任何二级索引在本次修改中需要修改，设置本次update的标记为UPD_NODE_NO_ORD_CHANGE，UPD_NODE_NO_ORD_CHANGE则代表不需要修改任何二级索引字段。注意这里还会转换为innodb的行格式（row_mysql_store_col_in_innobase_format）。
过滤点2，先修改主键，如果为UPD_NODE_NO_ORD_CHANGE update这不做二级索引更改，也就是不调用row_upd_sec_step函数，这是显然的，因为没有二级索引的字段需要更改（函数row_upd_clust_step中实现），这里对应了场景B，虽然 c3字段修改了数据，但是c1\c2字段前后的值一样，所以实际索引c1和索引c2不会更改，只修改主键索引。
如果需要更改二级索引，依次扫描字典中的每个二级索引循环开启。
过滤点3首选需要确认修改的二级索引字段是否在本索引中，如果修改的字段根本就没有在这个二级索引中，显然不需要修改本次循环的索引了。而这个判断在函数row_upd_changes_ord_field_binary中，方式为循环字典中本二级索引的每个字段判定
1.如果本字段不在m_prebuilt->upd_node->update数组中，直接进行下一个字段，说明本字段不需要修改
2.如果本字段在m_prebuilt->upd_node->update数组中，这进行调用函数dfield_datas_are_binary_equal进行比较，也就是比较实际的值是否更改
这里实际上对应了我们的场景3，因为c2字段的值没有更改，因此索引c2不会做实际的更改，但是主键索引和索引c1需要更改值。
结论
