Почему VARCHAR медленнее, чем CHAR, при обновлении строк?

Question

Я читал книгу:

Например, когда столбец определен как VARCHAR(25), максимальное количество поддерживаемых символов составляет 25, но на практике фактическое количество символов в строке определяет объем памяти. Потому что потребление памяти для этих типов данных меньше, чем для типов фиксированной длины, операции чтения выполняются быстрее. Однако обновления могут привести к расширению строки, что может привести к перемещению данных за пределы текущей страницы. Поэтому обновления данных, имеющих типы данных переменной длины, менее эффективны, чем обновления данных, имеющих типы данных фиксированной длины.

Я могу понять, что потребление памяти для varchar меньше, чем для char, но почему оно медленнее, чем char при обновлении записей? Что означает расширение строки и что на самом деле происходит при расширении строки?

Допустим, у нас есть таблица пригородов, которая имеет два столбца, zipcode char(5) и name varchar, и, скажем, нам нужно обновить запись строки с zipcode, чтобы быть 10005, и name, чтобы быть 'NYC' мы задаем только 3 символа для столбца имени, разве он не должен быть более эффективным, чем столбец zipcode, для которого требуется 5 символов?

Answer 1

Строки располагаются сначала со столбцами фиксированного размера, при фиксированных смещениях от начала строки. Затем (после нескольких важных байтов в середине) данные переменного размера помещаются в конец. Поскольку он имеет переменный размер, фактическое смещение данных не может быть вычислено для всей таблицы (например, фиксированных данных), но должно быть вычислено построчно.

И если varchar(5) ¹ хранит NYC, а затем его просят сохранить NYCX, может оказаться, что в конце NYC нет резервного байта - это используется для другого столбца - поэтому строка должна развернуть , перемещая все на один байт дальше, чтобы освободить место для дополнительного байта.

---

¹ Я заметил, что в одном из ваших примеров вы не указали длину. Пожалуйста, углубитесь в себя, что это вредная привычка