Немного смущен и нужен некоторый ввод.Использование PRIMARY KEY снижает размер файла innodb?
Я создал 2 таблицы здесь
CREATE TABLE `table1` (
`Id` int(11) NOT NULL AUTO_INCREMENT,
`Value` varchar(45) DEFAULT NULL,
PRIMARY KEY (`Id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `table2` (
`Value` varchar(45) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Когда я смотрю на размер файла в папке временных. Они оба 96 кб
Я просто вставляется 10240 элементы в обеих колонках.
SELECT count(*) FROM temp.table1;
SELECT count(*) FROM temp.table2;
дает
10240
10240
Если я теперь посмотрим на размер таблиц, это то, что я получаю.
Я обнаружил это, когда я изменил один из моих таблиц InnoDB и добавил AUTO_INCREMENT PRIMARY KEY
, а размер был более 3 Гб меньше.
У меня сложилось впечатление, что innodb имеет внутренний PRIMARY KEY
в случае, если один не определен? Но как может быть, что таблица с 1 столбцом меньше, на самом деле занимает больше места? Там нет индекса в table2
(кроме внутреннего PRIMARY KEY
), и PRIMARY KEY
определяется на table1
Означает ли это, что внутренний InnoDB PK использует BIGINT
например?
EDIT
После изменения PK в BIGINT, размеры файлов теперь одинаковы. Просто как тот.
Это, однако, вызывает другой вопрос. Является ли ПРЕДОСТЕРЕЖЕНИЕ MySQL
строк максимум BIGINT
(это большой да, но на самом деле есть предел, а затем правый)?
Что произойдет, если вы снова сбросите ключ? Становится ли оно больше или оно остается маленьким? MySQL в основном воссоздает всю таблицу для такого изменения, чтобы она могла реорганизовать данные в процессе, в результате чего файл сжимался. – GolezTrol
Кстати, 3 ГБ меньше по файлу 400 КБ? Возможно, вы имели в виду: «30KB less»? – GolezTrol
Внутренняя внутренняя схема POS имеет тип BIGINT, поэтому размер был другим. Но это создает для меня еще один вопрос относительно LIMIT для MySQL –