sql >> Database >  >> RDS >> Mysql

MySQL-prestaties verbeteren met geavanceerde InnoDB-instellingen

We hebben een tijdje geleden besproken hoe we InnoDB kunnen configureren voor hoge prestaties, maar we hebben nog niet besproken hoe we de MySQL-prestaties kunnen verbeteren door gebruik te maken van geavanceerde InnoDB-instellingen. Deze blogpost zou wat meer inzicht moeten geven in dit onderwerp.

InnoDB uitgelegd

Voordat we dieper ingaan op de InnoDB-instellingen, moeten we waarschijnlijk de basis begrijpen:InnoDB is een opslagengine voor MySQL, MariaDB en Percona Server. De engine stond bekend als InnoDB-plug-in, waarvoor de plug-in moet worden ingesteld en geïnstalleerd. Tot de release van MySQL 5.5.5 is InnoDB niet langer een plug-in en maakt het nu deel uit van het MySQL-pakket als een van de ondersteunde storage-engines voor MySQL. Sinds de release van MySQL 5.6 is InnoDB de standaard opslagengine geworden - het is een algemene opslagengine die een hoge betrouwbaarheid en hoge prestaties combineert. De belangrijkste voordelen van InnoDB zijn onder meer de ondersteuning van vergrendeling op rijniveau, externe sleutels en het volgen van het ACID-model (Atomicity Consistency Isolation Durability) - ACID is een reeks eigenschappen die bedoeld zijn om de geldigheid van gegevens te garanderen ondanks fouten, stroomstoringen en andere problemen. InnoDB heeft een uitgebreide lijst met variabelen en sommige hiervan helpen de prestaties te verbeteren, met name op het type hardware en beschikbare bronnen van uw databaseserver. Onder deze zijn:

  • innodb_data_file_path is het bestand waarin gegevens uit InnoDB-tabellen worden opgeslagen.
  • innodb_buffer_pool_size is een geheugenbuffer die InnoDB gebruikt om gegevens en indexen van zijn tabellen in de cache op te slaan.
  • innodb_log_file_size geeft de grootte van InnoDB-logbestanden weer. Hoe groter innodb_log_file_size, hoe langer de hersteltijd die je nodig hebt in geval van een crash.
  • innodb_log_buffer_size wordt door InnoDB gebruikt om naar de logbestanden op schijf te schrijven.
  • innodb_flush_log_at_trx_commit regelt de balans tussen prestaties en ACID-compliance. De standaardwaarde is 1, wat helpt om InnoDB ACID-compatibel te houden - als u innodb_flush_log_at_trx_commit naar 2 draait, krijgt u een zeer hoge schrijfsnelheid, maar tot een seconde aan transacties kan verloren gaan.

Er zijn ook geavanceerde InnoDB-instellingen die kunnen worden ingesteld om de MySQL-prestaties nog verder te verbeteren. We zullen ze nu bekijken.

Geavanceerde InnoDB-instellingen

Zoals hierboven al opgemerkt, heeft InnoDB geavanceerde instellingen die kunnen worden gebruikt om de prestaties ervan verder te verbeteren (we zullen ze niet absoluut allemaal opsommen, maar de instellingen die worden vermeld, zouden u een redelijk goed idee van hoe krachtig InnoDB werkelijk is):

  • InnoDB kan worden uitgeschakeld - als u InnoDB wilt uitschakelen, wijzigt u eenvoudig het my.cnf-bestand en voegt u skip-innodb toe onder de sectie [mysqld]. Start daarna uw MySQL-server opnieuw - InnoDB zou nu moeten zijn uitgeschakeld. Als alternatief kunt u de optie --innodb gebruiken:als u deze op OFF zet, wordt de engine uitgeschakeld. Houd er echter rekening mee dat deze opties zijn verouderd vanaf MySQL 5.7.5.
  • InnoDB biedt ook een configureerbaar vergrendelingsmechanisme dat de prestaties kan verbeteren van SQL-instructies die rijen toevoegen aan tabellen met AUTO_INCREMENT-kolommen:modi voor automatisch verhogen kunnen bij het opstarten worden geconfigureerd met behulp van de optie innodb_autoinc_lock_mode. De optie heeft drie instellingen voor het specificeren van de vergrendelingsmodus - de vergrendelingsmodus kan 0 (“traditioneel”), 1 (“opeenvolgend”) of 2 (“interleaved”) zijn. Waarden bieden prestaties afhankelijk van het type database-insert. Kortom, 0 biedt compatibiliteit met oudere versies van MySQL en Innodb. Waarde van 1 biedt meer veiligheid en deterministische benadering voor statement-based replicatie (SBR). Terwijl de waarde van 2 de meer schaalbare en snelste vergrendelingsmodus heeft, zijn rijen die door een bepaalde instructie worden ingevoegd, mogelijk niet opeenvolgend. Raadpleeg de MySQL-documentatie voor meer informatie.
  • InnoDB geeft je de mogelijkheid om de bufferpool in meerdere segmenten te verdelen (de functie is alleen beschikbaar vanaf MySQL 5.5) - met de instelling innodb_buffer_pool_instances kun je de schaalbaarheid van MySQL verbeteren op machines die meerdere cores draaien. Standaard is de waarde van deze instelling 1 als de innodb_buffer_pool_size kleiner is dan 1 GB en 8 anders:het getal geeft het aantal regio's aan waarin de InnoDB-bufferpool is verdeeld. Deze instelling kan worden gebruikt om meer kernen te activeren, we zullen later uitleggen hoe.
  • InnoDB biedt vier transactie-isolatieniveaus (tx_isolation in <5.7 maar transaction_isolation in versie 5.7 en hoger):LEZEN UNCOMMITTED, READ COMMITTED, REPEATABLE READ en SERIALIZABLE:deze isolatieniveaus zijn de "I" in het ACID-acroniem :
    • Als READ UNCOMMITTED in gebruik is, kan een transactie niet-vastgelegde wijzigingen zien door een andere transactie. Dit isolatieniveau staat vuile lezingen toe.
    • Als READ COMMITTED in gebruik is, kunt u er zeker van zijn dat alle gegevens die zijn gelezen, zijn vastgelegd op het moment dat ze werden gelezen.
    • Als REPEATABLE READ in gebruik is, wordt een hoger isolatieniveau gebruikt. Naast alles wat wordt gegarandeerd door het niveau READ COMMITTED, garandeert het ook dat gegevens die al zijn gelezen, niet kunnen veranderen.
    • Als SERIALIZABLE in gebruik is, is er een nog hoger isolatieniveau in gebruik. Naast alles wat wordt gegarandeerd door het REPEATABLE READ-isolatieniveau, garandeert het ook dat er geen nieuwe gegevens kunnen worden gezien door latere reads.
  • InnoDB stelt je ook in staat om de algemene I/O-capaciteit die beschikbaar is voor InnoDB te definiëren door de variabele innodb_io_capacity te wijzigen. De waarde van deze variabele moet worden ingesteld op ongeveer het aantal IOPS dat het systeem per seconde kan uitvoeren:houd er bij het instellen van de waarde van deze parameter rekening mee dat waarden rond 100 geschikter zijn voor HDD's, terwijl SSD's baat kunnen hebben bij hogere waarden . De variabele innodb_io_capacity_max kan ook van pas komen:met deze variabele kan InnoDB agressiever doorspoelen, wat betekent dat de snelheid van I/O-bewerkingen de limiet kan overschrijden die is gedefinieerd door innodb_io_capacity - in dergelijke situaties zullen de bewerkingen de waarde die is gedefinieerd door de variabele innodb_io_capacity_max niet overschrijden .
  • InnoDB stelt je ook in staat te bepalen hoeveel achtergrondthreads beschikbaar zijn voor I/O-bewerkingen:het aantal I/O-threads dat is toegewezen aan leesbewerkingen kan worden bepaald door de variabele innodb_read_io_threads, terwijl het aantal I/ O threads die zijn toegewezen aan schrijfbewerkingen kunnen worden beheerd door de variabele innodb_write_io_threads. De standaardwaarde voor beide parameters is 4 en de maximaal toegestane waarde is 64.
  • InnoDB heeft de mogelijkheid om bepaalde InnoDB-waarschuwingen om te zetten in fouten:om dit te doen, zet u de variabele innodb_strict_mode op ON:deze variabele beïnvloedt de verwerking van syntaxisfouten voor de bewerkingen CREATE TABLE, ALTER TABLE en CREATE INDEX :het uitschakelen van deze variabele kan de fouten "Rijgrootte te groot" oplossen. Om de strikte modus uit te schakelen, stelt u innodb_strict_mode in op UIT.
  • InnoDB kan enigszins worden beschermd tegen volledige tabelscans die interfereren met gegevens die in de bufferpool zijn opgeslagen door de variabele innodb_old_blocks_time te vergroten. De minimumwaarde voor deze instelling is 0, de standaardwaarde is 1000.
  • Als u onderhoudsbewerkingen uitvoert op InnoDB-tabellen die FULLTEXT-indexen bevatten, overweeg dan om de variabele innodb_optimize_fulltext_only op AAN te zetten - nadat deze variabele is ingeschakeld, zou de OPTIMIZE TABLE-query sneller moeten worden uitgevoerd omdat de reorganisatie van gegevens wordt overgeslagen in de tafel. Houd er rekening mee dat het de bedoeling is dat deze instelling slechts tijdelijk wordt ingeschakeld, dus u kunt deze instelling uitschakelen zodra de optimalisatie is voltooid.
  • Als u InnoDB in alleen-lezen modus wilt starten, schakelt u de instelling innodb_read_only in. Als deze instelling is ingeschakeld, kunt u InnoDB-tabellen opvragen waarbij de MySQL-gegevensdirectory zich op alleen-lezen media bevindt.

InnoDB meer cores aanspreken

Je kunt InnoDB ook meer cores laten gebruiken door gebruik te maken van de multithreading-mogelijkheden:verrassend genoeg is dit niet erg moeilijk te bereiken - je hoeft alleen maar een paar instellingen aan te passen. Zo doe je dat:

  1. Laat de innodb_thread_concurrency optie op de standaardwaarde 0 staan. Door dit te doen laat je InnoDB het beste aantal gelijktijdigheidstickets bepalen (ze bepalen het aantal threads dat gelijktijdig InnoDB kan binnenkomen) om te openen voor een bepaalde MySQL instantie instellen. Voor MariaDB vanaf 10.5 wordt het gemarkeerd als verouderd, dus het zou logisch zijn voor MySQL om dit op 0 in te stellen, aangezien de computerbronnen geavanceerd zijn in vergelijking met de begindagen van MySQL.
  2. Zodra de innodb_thread_concurrency optie is ingesteld op 0, stelt u zowel innodb_read_io_threads als innodb_write_io_threads in op hun maximale waarde van 64. Dit zou meer cores moeten betrekken.

Samenvatting

Om samen te vatten, InnoDB is een extreem krachtige opslagengine. De prestaties van deze opslagengine worden rechtstreeks beïnvloed door de instellingen die deze engine gebruikt. Dus als u de prestaties van uw MySQL-instantie wilt verbeteren, moet u rekening houden met ten minste enkele van de tips die in dit artikel worden genoemd. Als u de instellingen met betrekking tot de motor afstemt en deze indien nodig gebruikt, zou dit u een voordeel moeten opleveren.


  1. Hoe MySQL op macOS te installeren

  2. Wat is cursor in orakel

  3. Doe mee voor een Microsoft Access met SQL Server Academy-sessie

  4. Hoe Excel- of CSV-gegevens in de tabel in te voegen met behulp van de grafische gebruikersinterface in SQL Server - SQL Server / TSQL-zelfstudie, deel 102