Это действительно нужно измерить, мы можем сделать некоторые «догадки» на основе того, что мы знаем и что мы предполагаем, но это только догадки.
Вы не упомянули, является ли эта таблица InnoDB или MyISAM с динамическими строками или MyISAM с фиксированными строками длины. Это будет иметь значение.
Но для значений, подобных опубликованным, '961637593864109_412954765521130' (31 символа), если вы используете один байт (например, latin1) или набор символов, который кодирует эти конкретные символы в один байт (например, utf8). ..
Для динамического формата InnoDB и MyISAM это 31 + 1-8 = 24 дополнительных байта для этой строки. (BIGINT вписывается в 8 байтов, значение VARCHAR (31), равное 31 символу, будет использовать 32 байта.)
Для таблицы MyISAM с строками фиксированной длины это будет разница 23 байт в строке. (Пространство зарезервировано для всех 31 символа, и длина не должна быть сохранена.)
Это значение первичного ключа также будет повторяться в каждом индексе, так что с каждым индексом также увеличивается пространство.
Предполагая, что ваши строки таблицы составляют 120 байтов с использованием BIGINT, а строки - 144 байта с VARCHAR, это 20%. Чем больше ваши ряды, тем меньше процентное увеличение и наоборот.
Для 1 000 000 строк (я так хочу сказать «одни строки meelyun» так же, как доктор Злой кладет свой мизинец в угол этого рта и говорит «миллион долларов»), что дополнительные 24 байта на строку составляет около 24 МБ.
Но это не так-то просто. Что касается пространства InnoDB, это вопрос о том, как строки могут «вписаться» в блок. Чем больше средний размер строки, тем больше объем свободного места будет в блоке.
Если вы ничего не делаете со строками, кроме как хранить их на диске, то это просто увеличение дискового пространства и дополнительное время и пространство для резервного копирования.
Если же число «144 байта» строки помещаются в блоке как «120 байт» строк, то вы не будете видеть никакой разницы в пространстве. Но если меньше строк помещаются в блоке, это больше блоков, больше места в пуле буферов InnoDB, больше я/о и т.д.
Для запросов одной строки, либо значение первичного ключа, или по другой уникальный поиск по индексу, разница будет незначительной.
Если вы имеете дело с большими наборами результатов, то это дополнительная память для подготовки набора результатов и дополнительных байтов для передачи клиенту и т. Д.
Если ключ УАКСНАК сконструирован таким образом, что «группы» строк, которые доступны вместе имеют одинаковую начальную часть ключевого значения, то с InnoDB, может фактически быть некоторое улучшение производительности. Это потому, что основным ключом является кластерный ключ ... гораздо лучший шанс для строк, необходимых для удовлетворения запроса, находится в одном блоке, а не распределяется по кучке блоков.
Обратное, если выполнены вставки и удаления, в некоторых блоках будет больше свободного места. (При удалении пространство для удаленных строк остается в блоке; для его повторного использования вам нужно будет вставить строку с таким же значением ключа (или, по крайней мере, значение ключа, достаточно близкое, чтобы оно попало в один и тот же блок .) И со случайными вставками мы собираемся получить разбиения блоков.
при угадывании, пренебрежимо мало – Strawberry
У меня нет номеров, но это может быть значительным. Первичный ключ используется для сортировки данных таблицы и включен в каждом индексе, который вы создаете. Цель индексов состоит в том, чтобы прочитать небольшую часть таблицы, чтобы быстро идентифицировать релевантные записи. Если ваш первичный ключ является достаточно большим процентом данных строки, вы будете принуждать систему к сканированию таблиц. что, как правило, используется UniqueIdentifier, который состоит из 36 байтов. – jtimperley
Что представляют собой два числа в вашем VARCHAR? У вас может быть два значимых числовых столбца в один первичный ключ. Это предотвратит добавление случайных данных в качестве первичного ключа, сохраняя ваши данные согласованными. – jtimperley