MySQL：BUG導(dǎo)致DDL語(yǔ)句無(wú)謂的索引重建
一、問(wèn)題模擬
使用5.7.22版本：
建表語(yǔ)句，注意這里字段a包含了一個(gè)索引，這是觸發(fā)這個(gè)BUG的必要條件：
mysql> show create table testmy \G
*************************** 1. row ***************************
Table: testmy
Create Table: CREATE TABLE `testmy` (
`id` int(11) DEFAULT NULL,
`a` varchar(24) DEFAULT NULL COMMENT 'test1',
KEY `a` (`a`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
數(shù)據(jù)量：
mysql> select count(*) from testmy;
+----------+
| count(*) |
+----------+
| 262144 |
+----------+
1 row in set (5.17 sec)
執(zhí)行DDL語(yǔ)句：
alter table testmy modify `a` varchar(30) comment 'test1111';本DDL語(yǔ)句主要完成：
- 擴(kuò)展varchar從24*4到30*4
- 更改字段的comment
按照常理來(lái)講這個(gè)DDL是只修改元數(shù)據(jù)的，因此應(yīng)該瞬間完成，但是實(shí)際在5.7.22版本中這個(gè)語(yǔ)句重建了索引a，耗時(shí)如下：
mysql> alter table testmy modify `a` varchar(30) comment 'test1';
Query OK, 0 rows affected (2.50 sec)
Records: 0 Duplicates: 0 Warnings: 0很明顯重建了索引，才會(huì)有這么高的耗時(shí)。而在5.7的新版本或者8.0中測(cè)試這個(gè)語(yǔ)句是瞬間完成的。
二、官方文檔說(shuō)明
也就是說(shuō)正常的擴(kuò)展varchar的長(zhǎng)度，只要字符集字節(jié)數(shù)量*字符數(shù)量不跨越256，那么就是修改元數(shù)據(jù)，不會(huì)重建索引。
三、問(wèn)題分析
既然不符合官方文檔的說(shuō)明，那么這個(gè)問(wèn)題肯定是某種BUG導(dǎo)致。當(dāng)我們進(jìn)行DDL操作的時(shí)候，需要對(duì)比更改部分和現(xiàn)有的數(shù)據(jù)字典中標(biāo)定義的差別，然后根據(jù)這些差別來(lái)定義操作方式，然后根據(jù)操作方式來(lái)判斷哪一種DDL 方式比較合適，關(guān)于定義操作方式的部分來(lái)自于函數(shù)fill_alter_inplace_info，而在函數(shù)中會(huì)根據(jù)新表的索引和老表的索引字段的長(zhǎng)度判斷是否需要drop索引和新建索引，代碼中體現(xiàn)為如下：
/*
Step through all keys of the old table and search matching new keys.
*/
for (table_key= table->key_info; table_key < table_key_end; table_key++) //循環(huán)老表的索引
{
/* Skip renamed keys. */
if (table_key->flags & HA_KEY_RENAMED)
continue;
new_key= find_key_cs(table_key->name, ha_alter_info->key_info_buffer,
new_key_end);//在新的定義中是否包含這個(gè)索引
if (new_key == NULL) //如果找不到說(shuō)明這個(gè)索引要drop掉
{
/* Matching new key not found. This means the key should be dropped. */
ha_alter_info->add_dropped_key(table_key); //加入到drop key buffer
}
else if (has_index_def_changed(ha_alter_info, table_key, new_key))//是否索引有所改變
{
/* Key was modified. */
ha_alter_info->add_modified_key(table_key, new_key); //加入到modify key buffer
}
}而加入到modify buffer后這個(gè)索引就是需要drop并且add的，因此DDL類(lèi)型定義為，Alter_inplace_info::DROP_INDEX|Alter_inplace_info::ADD_INDEX，因此就需要進(jìn)行索引的刪除和重建，因此關(guān)鍵就是函數(shù)has_index_def_changed的更改，我們先看5.7.22的這個(gè)BUG相關(guān)的判斷點(diǎn)：
if (key_part->length != new_part->length)
return true; 也就是當(dāng)索引字段長(zhǎng)度更改了就返回true。而在新版本中：
if (key_part->length != new_part->length &&
ha_alter_info->alter_info->flags == Alter_info::ALTER_CHANGE_COLUMN &&
(key_part->field->is_equal((Create_field *)new_field) == IS_EQUAL_PACK_LENGTH))
{
ha_alter_info->handler_flags|=
Alter_inplace_info::ALTER_COLUMN_INDEX_LENGTH;
}
else if (key_part->length != new_part->length)
return true;變更還是比較大的，主要是key_part->field->is_equal((Create_field *)new_field) == IS_EQUAL_PACK_LENGTH)這個(gè)條件是否滿(mǎn)足，而判定的函數(shù)為Field_varstring::is_equal，
uint Field_varstring::is_equal(Create_field *new_field)
{
if (new_field->sql_type == real_type() &&
new_field->charset == field_charset)
{
if (new_field->length == max_display_length()) //新老字段長(zhǎng)度相同
return IS_EQUAL_YES;
DBUG_ASSERT(0 == (new_field->length % field_charset->mbmaxlen));
DBUG_ASSERT(0 == (max_display_length() % field_charset->mbmaxlen));
if (new_field->length > max_display_length() && //新字段長(zhǎng)度大于老字段長(zhǎng)度，需要額外判斷
((new_field->length <= 255 && max_display_length() <= 255) ||
(new_field->length > 255 && max_display_length() > 255)))
return IS_EQUAL_PACK_LENGTH; // VARCHAR, longer variable length
}
return IS_EQUAL_NO;
}其重點(diǎn)為如下：
- A:如果新的字段長(zhǎng)度>老的字段的長(zhǎng)度
- B:字段長(zhǎng)度不能跨越255字節(jié)
那么則返回IS_EQUAL_PACK_LENGTH，因此就這個(gè)點(diǎn)上has_index_def_changed函數(shù)就會(huì)返回false，不會(huì)刪除和重建索引了。
四、相關(guān)BUG
這個(gè)BUG雖然有點(diǎn)老了，是5.7.23修復(fù)的，如下：
但是對(duì)于5.7.23之前的版本在評(píng)估類(lèi)似DDL操作的時(shí)候需要謹(jǐn)慎，可能評(píng)估為瞬間操作，但是實(shí)際上線(xiàn)的時(shí)候跑了很久，這個(gè)就容易導(dǎo)致超過(guò)維護(hù)窗口，甚至更大的故障，因此還是建議任何DDL操作除了翻看官方文檔以外，都需要在相同版本的數(shù)據(jù)庫(kù)測(cè)試環(huán)境測(cè)試其耗時(shí)是否達(dá)到預(yù)估水平。
