Експериментирах малко с тази концепция при предишна работа, където се нуждаехме от бърз метод за копиране на схеми между MySQL сървъри.
Наистина има излишни разходи за производителност, когато вмъквате в таблици, които имат вторични индекси. Вмъкванията трябва да актуализират клъстерирания индекс (известен още като таблицата), както и да актуализират вторичните индекси. Колкото повече индекси има една таблица, толкова повече излишни разходи причинява за вмъкванията.
InnoDB има функция, наречена буфер за промяна което помага малко, като отлага актуализациите на индексите, но в крайна сметка те трябва да бъдат обединени.
Вмъкванията в таблица без вторични индекси са по-бързи, така че е изкушаващо да се опитате да отложите създаването на индекс, докато данните ви не бъдат заредени, както описвате.
Percona Server, клон на MySQL, експериментира с mysqldump --optimize-keys опция. Когато използвате тази опция, тя променя изхода на mysqldump, за да има CREATE TABLE без индекси, след това INSERT всички данни, след това ALTER TABLE, за да добавите индексите, след като данните се заредят. Вижте https://www.percona.com/doc/ percona-server/LATEST/management/innodb_expanded_fast_index_creation.html
Но според моя опит нетното подобрение в производителността беше малко. Все още отнема известно време, за да се вмъкнат много редове, дори за таблици без индекси. След това възстановяването трябва да изпълни ALTER TABLE за изграждане на индексите. Това отнема известно време за голяма маса. Когато преброите времето на INSERT плюс допълнителното време за изграждане на индекси, това е само няколко (ниски едноцифрени) процента по-бързо от вмъкването по традиционния начин в таблица с индекси.
Друго предимство на това създаване на индекс с последваща обработка е, че индексите се съхраняват по-компактно, така че ако трябва да спестите дисково пространство, това е по-добра причина да използвате тази техника.
Открих, че е много по-изгодно за производителността да се възстанови чрез зареждане на няколко таблици паралелно .
- Новият инструмент MySQL 8.0 mysqlpump поддържа многонишково изхвърляне.
- Инструментът с отворен код mydumper
поддържа многонишков дъмп и също така има многонишков инструмент за възстановяване, наречен
myloader. Най-лошият недостатък на mydumper/myloader е, че документацията на практика не съществува, така че трябва да сте безстрашен опитен потребител, за да разберете как да я стартирате.
Друга стратегия е да използвате mysqldump --tab да изхвърляте CSV файлове вместо SQL скриптове. Груповото зареждане на CSV файлове е много по-бързо от изпълнението на SQL скриптове за възстановяване на данните. Е, той изхвърля SQL файл за дефиницията на таблицата и CSV за данните за импортиране. Създава отделни файлове за всяка таблица. Трябва ръчно да пресъздадете таблиците, като заредите всички SQL файлове (това е бързо) и след това използвате mysqlimport
за да заредите CSV файловете с данни. Инструментът mysqlimport дори има --use-threads опция за паралелно изпълнение.
Тествайте внимателно с различен брой успоредни нишки. Моят опит е, че 4 нишки е най-доброто. С по-голям паралелизъм InnoDB се превръща в тесно място. Но вашето преживяване може да е различно, в зависимост от версията на MySQL и производителността на хардуера на сървъра ви.
Най-бързият метод за възстановяване от всички е, когато използвате инструмент за физическо архивиране, най-популярният е Percona XtraBackup . Това позволява бързо архивиране и дори по-бързо възстановяване. Архивираните файлове са буквално готови да бъдат копирани на място и използвани като файлове на живо пространство за таблици. Недостатъкът е, че трябва да изключите вашия MySQL сървър, за да извършите възстановяването.
