MySQL CPU 100% hög lösning

Lilla avskum · Publicerad på 2018-10-11 11:20:31

Öppna serverns aktivitetshanterare och se att CPU-processen alltid har varit 99 %, och vyn är upptagen av MySQL-processen, som har varit hög.

Inloggningen är synlig.

Utdata från processlist-kommandot visar vilka trådar som körs, och du kan kontrollera databasens aktuella körstatus.

1. Gå till mysql/bin-katalogen och skriv in mysqladmin processlist;
2. Starta MySQL och ange visa processlista.
Om du har SUPER-behörighet kan du se alla trådar, annars kan du bara se trådarna på ditt konto.

Betydelsen och syftet med varje kolumn

id: En identifierare
user: visar den nuvarande användaren, om den inte är root kommer detta kommando endast att visa SQL-satser inom dina behörigheter.
host: visar vilken IP detta uttalande kommer från vilken port
db: Visar databasen som processen för närvarande är ansluten till.
kommando: Visar kommandon som utförs av den aktuella anslutningen, vanligtvis viloläge, fråga och ansluta.
tid: Den tid detta tillstånd varar, i sekunder.
Tillstånd: Visar statusen för SQL-satsen som använder den aktuella anslutningen, men endast ett visst tillstånd i exekveringen av satsen, en SQL-sats, har förfrågats, till exempel kan den behöva gå igenom kopiering till tmp-tabell, sorteringsresultat, sändande data, etc
info: Visar denna SQL-sats, eftersom längden är begränsad, så den långa SQL-satsen visas inte fullt ut, men den är en viktig grund för att bedöma problemsatsen.

Det visar sig att det finns två SQL-frågesatser som tar längst tid och inte har körts mer än 1000 sekunder, och de SQL-satser vi kopierade från infofältet är en gemensam fråga, enligt följande:

Välj cast(count(*) som SIGNED) som col_0_0_ från 'RatedPassenger' ratedpasse0_, 'BaseInfoCompany' baseinfoco1_, 'OrderMatch' ordermatch2_ där baseinfoco1_. CompanyId=ratedpasse0_. FöretagsID och ordermatch2_. OrderId=ratedpasse0_. OrderId

Vi dödar processen med dessa två frågesatser

Inloggningen är synlig.

Efter att ha väntat i 10 sekunder upptäckte jag att CPU:n hade tappat mycket, men den var fortfarande väldigt hög, och jag kommer fortsätta att fråga orsaken!

För join-gemensam frågesats, lägg till ett index i det tillhörande fältet eller modifiera programfrågekoden.
Skapa en index-SQL-sats

Inloggningen är synlig.

Slut

Lilla avskum · Publicerad på 2018-10-11 13:03:02

Det mest kritiska av detta kommando är statuskolumnen, och tillstånden som listas i MySQL är huvudsakligen följande:

Kontrollbord
  Att kontrollera databladet (detta är automatiskt).
  Avslutningstabeller
  Den data som ändrats i tabellen rensas till disken, och tabellen som har använts stängs. Detta är en snabb åtgärd, annars bör du kontrollera om diskutrymmet är fullt eller om disken är belastad.
  Koppla upp sig
  Replikeringsslavservern ansluter till primärservern.
  Kopiering till tmp-tabell på disk
  Eftersom den tillfälliga resultatmängden är större än tmp_table_size, konverteras den tillfälliga tabellen från minnet till disklagring för att spara minne.
  Skapa tmp-tabell
  En tillfällig tabell skapas för att hålla vissa av frågeresultaten.
  Radering från huvudtabellen
  Servern utför den första delen av en multi-tabellsradering och har precis raderat den första tabellen.
  Radering från referenstabeller
  Servern utför den andra delen av multi-table deletering, vilket innebär att ta bort poster från andra tabeller.
  Flushing-tabeller
  Gör FLUSH TABLES, väntar på att andra trådar stänger datatabellen.
  Dödad
  Om en kill-förfrågan skickas till en tråd kommer tråden att kontrollera kill-flaggan och avbryta nästa kill-begäran. MySQL kontrollerar efter kill-flaggor i varje huvudloop, även om tråden i vissa fall kan dö under en kort tid. Om tråden låses av en annan tråd träder dödsförfrågan i kraft omedelbart när låset släpps.
  Låst
  Låst av andra frågor.
  Sändning av data
  Posten för SELECT-frågan bearbetas medan resultaten skickas till klienten.
  Sortering efter grupp
  Sorterar efter GRUPP.
  Sortering efter ordning
  Sortering görs för ORDER BY.
  Öppningsbord
  Denna process bör gå snabbt om den inte störs av andra faktorer. Till exempel kan en datatabell inte öppnas av en annan tråd förrän satsen ALTER TABLE eller LOCK TABLE har körts. Försöker öppna ett bord.
  Borttagning av dubbletter
  En select distinkt-fråga körs, men MySQL kan inte optimera de dubblettposter i föregående steg. Därför måste MySQL ta bort de dubblettposter igen innan resultaten skickas till klienten.
  Återöppningsbordet
  Ett lås på en tabell erhålls, men det måste ändras efter att tabellstrukturen har ändrats. Har redan släppt låset, stängt databladet och försöker öppna datatabellen igen.
  Reparation genom sortering
  Fix-instruktionen sorterar för att skapa ett index.
  Reparation med keycache
  Fix-direktivet är att använda indexcachen för att skapa nya index ett efter ett. Det kommer att vara långsammare än Reparation genom sortering.
  Söker rader efter uppdatering
  Behöriga poster identifieras för uppdateringar. Det måste göras innan UPPDATERINGEN ändrar den relevanta posten.
  Sovande
  Väntar på att klienten ska skicka en ny förfrågan.
  Systemlås
  Väntar på att få ett externt systemlås. Om det inte finns några mysqld-servrar som körs samtidigt och begär samma tabell, kan externa systemlås förbjudas genom att lägga till parametern –skip-external-locking.
  Uppgradering av sluss
  INSERT DELAYED försöker få en låstabell att infoga en ny post.
  Uppdatering
  Söker efter matchande poster och ändrar dem.
  Användarlås
  väntar på GET_LOCK().
  Servering för bord
  Tråden fick besked om att databladsstrukturen hade modifierats och behövde öppnas igen för att få den nya strukturen. För att öppna datatabellen igen måste du sedan vänta tills alla andra trådar stänger tabellen. Denna notifikation sker i följande fall: FLUSH TABLES tbl_name, ÄNDRA TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE eller OPTIMIZE TABLE.
  väntar på handler-insats
  INSERT DELAYED har behandlat alla väntande insättningar och väntar på en ny förfrågan.
  De flesta tillstånd motsvarar snabba operationer, så länge en tråd stannar i samma tillstånd i några sekunder kan det finnas ett problem som behöver kontrolleras.

Lilla avskum · Publicerad på 2019-03-01 10:26:49

Officiell dokumentationslänk:https://dev.mysql.com/doc/refman/5.7/en/show-processlist.html

Lilla avskum · Publicerad på 2019-03-01 10:34:13

Inloggningen är synlig.

Det tar 10 sekunder att fråga en data.

[Källa] MySQL CPU 100% hög lösning

Relaterade inlägg

Avsnitt som ses