Mysql
 sql >> база данни >  >> RDS >> Mysql

Подобряване на производителността на MySQL с разширени настройки на InnoDB

Преди известно време обсъдихме как да конфигурираме InnoDB за висока производителност, но все още не сме обсъждали как можем да подобрим производителността на MySQL, като използваме разширени настройки на InnoDB. Тази публикация в блога трябва да даде малко повече поглед върху тази тема.

Обяснение на InnoDB

Преди да се потопим по-дълбоко в настройките на InnoDB, вероятно трябва да разберем основите:InnoDB е машина за съхранение за MySQL, MariaDB и Percona Server. Двигателят беше известен като InnoDB Plugin, който изисква настройка и инсталиране на приставката. До пускането на MySQL 5.5.5, InnoDB вече не е плъгин и вече е част от пакета MySQL като една от поддържаните машини за съхранение на MySQL. След пускането на MySQL 5.6,  InnoDB се превърна в машина за съхранение по подразбиране – това е машина за съхранение с общо предназначение, която балансира висока надеждност и висока производителност. Основните предимства на InnoDB включват поддръжка на заключване на ниво ред, външни ключове и следване на модела ACID (Atomicity Consistency Isolation Durability) – ACID е набор от свойства, които са предназначени да гарантират валидност на данните въпреки грешки, прекъсване на захранването и други проблеми. InnoDB има обширен списък от променливи и някои от тях помагат за подобряване на производителността, особено на типа хардуер и наличните ресурси на вашия сървър на база данни. Сред тях са:

  • innodb_data_file_path е файлът, в който се съхраняват данни от InnoDB таблици.
  • innodb_buffer_pool_size е буфер на паметта, който InnoDB използва за кеширане на данни и индекси на своите таблици.
  • innodb_log_file_size изобразява размера на регистрационните файлове на InnoDB. Колкото по-голям е innodb_log_file_size, толкова по-дълго е времето за възстановяване, от което се нуждаете в случай на срив.
  • innodb_log_buffer_size се използва от InnoDB за запис в регистрационните файлове на диска.
  • innodb_flush_log_at_trx_commit контролира баланса между производителността и съответствието с ACID. Стойността по подразбиране е 1, което помага да се поддържа InnoDB ACID съвместим – превръщането на innodb_flush_log_at_trx_commit на 2 получава много бърза скорост на запис, но транзакциите на стойност до една секунда могат да бъдат загубени.

Има и разширени настройки на InnoDB, които могат да бъдат настроени, за да подобрят още повече производителността на MySQL. Сега ще ги разгледаме.

Разширени настройки на InnoDB

Както вече беше отбелязано по-горе, InnoDB има разширени настройки, които могат да се използват за по-нататъшно подобряване на производителността му (няма да изброяваме абсолютно всички, но изброените настройки трябва да ви дадат доста добра идея колко мощен всъщност е InnoDB):

  • InnoDB може да бъде деактивиран - ако искате да деактивирате InnoDB, просто модифицирайте файла my.cnf и добавете skip-innodb в секцията [mysqld]. След това рестартирайте вашия MySQL сървър - InnoDB вече трябва да бъде деактивиран. Като алтернатива можете да използвате опцията --innodb:настройването й на OFF деактивира двигателя. Въпреки това имайте предвид, че тези опции са отхвърлени от MySQL 5.7.5.
  • InnoDB също така предоставя конфигурируем механизъм за заключване, който може да подобри производителността на SQL изрази, които добавят редове към таблици с AUTO_INCREMENT колони:режимите на автоматично увеличение могат да бъдат конфигурирани при стартиране с помощта на опцията innodb_autoinc_lock_mode. Опцията има три настройки за определяне на режима на заключване - режимът на заключване може да бъде 0 („традиционен“), 1 („последователен“) или 2 („interleaved“). Стойностите предлагат производителност в зависимост от типа вмъкване на база данни. Накратко, 0 предлага съвместимост с по-стари версии на MySQL и Innodb. Стойността 1 предлага повече безопасност и детерминиран подход за репликация, базирана на изрази (SBR). Докато стойността на 2 има по-мащабируем и най-бърз режим на заключване, но редовете, вмъкнати от който и да е израз, може да не са последователни. Вижте документацията на MySQL за повече информация.
  • InnoDB ви дава възможността да разделяте буферния пул на множество сегменти (функцията е достъпна само от MySQL 5.5) - настройката innodb_buffer_pool_instances ви позволява да подобрите мащабируемостта на MySQL на машини, които работят с множество ядра. По подразбиране стойността на тази настройка е 1, ако innodb_buffer_pool_size е по-малък от 1GB и 8 в противен случай:числото определя броя на регионите, на които е разделен буферният пул InnoDB. Тази настройка може да се използва за ангажиране на повече ядра, ще обясним как по-късно.
  • InnoDB предлага четири нива на изолация на транзакциите (tx_isolation в <5.7, но transaction_isolation във версия 5.7 и по-нататък):ПРОЧЕТЕНЕ НЕЗАДЪЛЖЕНО, ПРОЧЕТЕТЕ COMMITTED, ПОВТОРЯЩО ЧЕТЕНЕ и СЕРИАЛИЗИРАНО:тези нива на изолация са "I" в ACID акронима :
    • Когато се използва READ UNCOMMITTED, една транзакция може да види незаети промени от друга транзакция. Това ниво на изолация позволява мръсно четене.
    • Когато се използва READ COMMITTED, можете да сте спокойни, че всички прочетени данни са били записани в момента, в който са били прочетени.
    • Когато се използва REPEATABLE READ, се използва по-високо ниво на изолация. В допълнение към всичко, което е гарантирано от нивото READ COMMITTED, то също така гарантира, че всички данни, които вече са прочетени, не могат да се променят.
    • Когато се използва SERIALIZABLE, се използва още по-високо ниво на изолация. В допълнение към всичко, което е гарантирано от нивото на изолация ПОВТОРЯЩОТО ЧЕТЕНЕ, то също така гарантира, че няма да се видят нови данни при последващи четения.
  • InnoDB също така ви позволява да дефинирате общия I/O капацитет, наличен за InnoDB, като модифицирате променливата innodb_io_capacity. Стойността на тази променлива трябва да бъде настроена на приблизително броя IOPS, които системата може да изпълнява в секунда:когато задавате стойността на този параметър, имайте предвид, че стойностите около 100 са по-подходящи за твърди дискове, докато SSD може да се възползват от по-високи стойности . Променливата innodb_io_capacity_max също може да бъде от помощ:тази променлива позволява на InnoDB да промива по-агресивно, което означава, че скоростта на I/O операции може да надхвърли границата, определена от innodb_io_capacity - в такива ситуации операциите няма да надвишават стойността, дефинирана от променливата innodb_io_capacity_max .
  • InnoDB също така ви позволява да контролирате колко фонови нишки са налични за I/O операции:броят на I/O нишки, разпределени за операции за четене, може да се контролира от променливата innodb_read_io_threads, докато броят на I/O O нишки, разпределени за операции по запис, могат да бъдат контролирани от променливата innodb_write_io_threads. Стойността по подразбиране и за двата параметъра е 4, а максималната разрешена стойност е 64.
  • InnoDB има способността да превръща определени предупреждения на InnoDB в грешки:за да направите това, просто задайте променливата innodb_strict_mode на ON:тази променлива влияе върху обработката на синтактични грешки за операции CREATE TABLE, ALTER TABLE и CREATE INDEX :деактивирането на тази променлива може да реши грешките „Размерът на ред е твърде голям“. За да деактивирате строг режим, задайте innodb_strict_mode на OFF.
  • InnoDB може да бъде донякъде защитен срещу пълно сканиране на таблици, което пречи на данните, кеширани в буферния пул, чрез увеличаване на променливата innodb_old_blocks_time. Минималната стойност за тази настройка е 0, стойността по подразбиране е 1000.
  • Ако изпълнявате операции по поддръжка на таблици InnoDB, които съдържат FULLTEXT индекси, помислете за включване на променливата innodb_optimize_fulltext_only на ON - след като тази променлива е активирана, заявката OPTIMIZE TABLE трябва да работи по-бързо, защото ще пропусне реорганизацията на данните на масата. Имайте предвид, че тази настройка е предназначена да бъде активирана само временно, така че може да искате да я изключите, след като оптимизацията приключи.
  • За да стартирате InnoDB в режим само за четене, активирайте настройката innodb_read_only. Когато тази настройка е активирана, можете да правите заявки за InnoDB таблици, където MySQL директорията с данни е на носител само за четене.

Накарайте InnoDB да ангажира повече ядра

Можете също да накарате InnoDB да ангажира повече ядра, като се възползвате от възможностите му за многонишковост:изненадващо, това не е много трудно за постигане - просто трябва да промените няколко настройки. Ето как да направите това:

  1. Оставете опцията innodb_thread_concurrency на нейната стойност по подразбиране 0. По този начин позволявате на InnoDB да реши най-добрия брой билети за паралелност (те определят броя на нишките, които могат едновременно да влизат в InnoDB), които да се отварят за даден MySQL настройка на инстанция. За MariaDB, започваща от 10.5, той е маркиран като остарял, така че би имало смисъл MySQL да зададе това на 0, тъй като изчислителните ресурси са били сложни в сравнение с ранните дни на MySQL.
  2. След като опцията innodb_thread_concurrency е зададена на 0, задайте както innodb_read_io_threads, така и innodb_write_io_threads на максималните им стойности от 64. Това трябва да ангажира повече ядра.

Резюме

За да обобщим, InnoDB е изключително мощен двигател за съхранение. Производителността на този механизъм за съхранение се влияе пряко от настройките, които този двигател използва. Така че, ако искате да подобрите производителността на вашия MySQL екземпляр, не забравяйте да имате предвид поне няколко от съветите, споменати в тази статия. Настройването на настройките по отношение на двигателя и използването им, когато е подходящо, би трябвало да ви даде предимство.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Как да промените Root парола на MySQL или MariaDB в Linux

  2. Има ли MySQL опция/функция за проследяване на историята на промените в записи?

  3. Индекс на PostgreSQL срещу индекс InnoDB - Разбиране на разликите

  4. Възможно ли е да има индексиран изглед в MySQL?

  5. Грешка при стартиране на MySQL сървъра „Сървърът излезе без актуализиране на PID файл“