Влияние производительности на добавление индекса MySQL в большую таблицу

Question

Мы хотели бы добавить нормальный индекс в поле следующей таблицы MySQL и хотели бы понять влияние на производительность сервера перед этим. Например. будет ли индекс получать дополнительную оперативную память и замедлить базу данных в результате?

Мы понимаем, что для создания индекса потребуется время. нас это не беспокоит. скорее, мы хотим знать, нужно ли нам обновлять наш сервер, чтобы предвидеть потенциальное увеличение нагрузки/давления памяти в базу данных после добавления индекса. наш dba настаивает на том, что мы должны увеличить объем оперативной памяти с 16 ГБ до 48 ГБ, поскольку он считает, что новый индекс будет храниться в ОЗУ, что приведет к тому, что у сервера закончится нехватка памяти для других операций. было бы здорово подтвердить, что это необходимо.

Заранее благодарим за советы экспертов. версия

MySQL: 5.5.30

ОС: CentOS

Оборудование конфигурации: 8 Ядро, 32G ОЗУ, 1 ТБ диск

Размер стола: 490GB

Количество строк: 67M

CREATE TABLE `mytable` (
    `field_1` text NOT NULL, 
    `field_2` varchar(200) NOT NULL, 
    `field_3` varchar(100) NOT NULL, 
    `field_4` text NOT NULL, 
    `field_5` char(8) NOT NULL, 
    `field_6` varchar(100) NOT NULL DEFAULT '', 
    `field_7` varchar(100) DEFAULT '', 
    `field_8` varchar(20) NOT NULL, 
    `field_9` char(16) NOT NULL, 
    `field_0` varchar(25) NOT NULL, 
    `field_a` varchar(50) NOT NULL DEFAULT '', 
    `field_b` varchar(20) DEFAULT '', 
    `field_c` varchar(35) DEFAULT '', 
    `field_d` varchar(35) DEFAULT '', 
    `field_e` varchar(30) NOT NULL DEFAULT '', 
    `field_f` varchar(30) DEFAULT '', 
    `field_g` varchar(3) NOT NULL DEFAULT 'xx', 
    `field_h` varchar(50) DEFAULT '', 
    `field_i` varchar(100) DEFAULT '', 
    `field_j` char(8) NOT NULL, 
    `field_k` varchar(10) NOT NULL DEFAULT '', 
    `field_l` datetime NOT NULL, 
    PRIMARY KEY (`field_9`), 
    KEY `field_j_idx` (`field_j`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8; 

Answer 1

Прежде всего, индексы хранятся на диске, а не в памяти. Как MyISAM, так и innodb могут кэшировать определенные блоки индекса в память, чтобы обеспечить быстрый доступ к наиболее часто используемым блокам. Для innodb размер этого буфера контролируется системной переменной сервера innodb_buffer_pool_size.

Как видно из описания, установка этой переменной не зависит от добавления или удаления индексов. Таким образом, если вы не решите увеличить размер этой переменной, нет прямого влияния на добавление нового индекса в использование памяти MySQL.

Очевидно, что добавление нового индекса в большую существующую таблицу будет иметь влияние на производительность при создании индекса. При добавлении индекса в любые операции вставки/обновления/удаления будет очевидным следствием, так как MySQL также должен будет обновить дополнительные данные индекса.

Answer 2

Это зависит. Какая версия MySQL у вас есть? С более новыми версиями ALGORITHM=INPLACE делает добавление вторичного, неидеального, индекса относительно быстрого и безболезненного.

У вас возникла еще одна потенциальная проблема. Если эта таблица на самом деле вдвое меньше размера диска, если вам нужно сделать ALTER, что не может быть сделано с INPLACE, это, вероятно, произойдет из-за нехватки дискового пространства. Подумайте о том, чтобы получить больший диск, прежде чем это произойдет, и/или подумайте о способах сокращения таблицы.

CHAR(8) - какие данные в нем? Если это всегда шестнадцатеричные или простые буквы, он должен быть объявлен CHARACTER SET ascii (или latin1), а не utf8 - который принимает 24 байта. Field_j уже принимает двойное значение из-за индекса.

Если некоторые из столбцов имеют повторяющиеся значения, рассмотрите их «нормализацию». Затем замените массивную строку на MEDIUMINT UNSIGNED (3 байта, максимум 16M) или INT UNSIGNED.

(Я понимаю вашу потребность в обфускации имен столбцов, но это затрудняет предоставление конкретных предложений.)

field_4TEXT, который не может быть проиндексирован. Опишите, пожалуйста, какой тип текста в нем; мы можем предложить обходные пути.

Предполагаю, innodb_file_per_table=ON, когда вы построили стол? А еще ON? Иначе вся надежда потеряна.