Re Slowlog:Visa oss din my.cnf. Var ändringarna i [mysqld] sektion? Testa det via SELECT SLEEP(12); , titta sedan både i filen och tabellen.
Alternativt sätt att hitta frågan:Eftersom frågan tar flera minuter, gör du SHOW FULL PROCESSLIST; när du tror att den kan vara igång.
Hur mycket RAM-minne har du? Gör inte har max_allowed_packet=300M om du inte har minst 30 GB RAM. Annars riskerar du att byta (eller till och med krascha). Håll den inställningen under 1 % av RAM-minnet.
För ytterligare analys av tunables, ange (1) RAM-storlek, (2) SHOW VARIABLES; och (3) SHOW GLOBAL STATUS; .
Re deleted_at :Den länken du gav börjar med "Kolumnen deleted_at är inte en bra indexkandidat". Du misstolkade det. Det handlar om en enkolumn INDEX(deleted_at) . Jag föreslår ett sammansatt index som INDEX(contact_id, job_class_name, execute_at, deleted_at) .
158 sekunder för en enkel fråga på ett litet bord? Det kan vara så att det finns mycket annat saker på gång. Hämta PROCESSLIST .
Om separata index kontra sammansatta:Tänk på två index:INDEX(last_name) och INDEX(first_name) . Du bläddrar igenom efternamnsindexet för att hitta "James", vad kan du göra då? Att bläddra igenom det andra indexet för "Rick" hjälper dig inte att hitta mig.
Analyse av VARIABLER och GLOBAL STATUS
Observationer:
- Version:5.7.22-log
- 1,00 GB RAM
- Upptid =16d 10:30:19
- Är du säker på att detta var en VISA GLOBAL STATUS?
- Du kör inte på Windows.
- Kör 64-bitarsversion
- Du verkar köra helt (eller mestadels) InnoDB.
De viktigare frågorna:
innodb_buffer_pool_size -- Jag trodde du hade den på 213M, inte 10M. 10M är alldeles för litet. Å andra sidan verkar du ha mindre än så mycket data.
Eftersom RAM-minnet är så litet rekommenderar jag att släppa tmp_table_size och max_heap_table_size och max_allowed_packet till 8M. Och sänk table_open_cache, table_definition_cache och innodb_open_files till 500.
Vad orsakar så många samtidiga anslutningar?
Detaljer och andra observationer:
( innodb_buffer_pool_size / _ram ) = 10M / 1024M = 0.98% -- % av RAM som används för InnoDB buffer_pool
( innodb_buffer_pool_size ) = 10M -- InnoDB Data + Indexcache
( innodb_lru_scan_depth ) = 1,024 -- "InnoDB:page_cleaner:1000 ms avsedd loop tog ..." kan fixas genom att sänka lru_scan_depth
( Innodb_buffer_pool_pages_free / Innodb_buffer_pool_pages_total ) = 375 / 638 = 58.8% -- Pct av buffer_pool används för närvarande inte -- innodb_buffer_pool_size är större än nödvändigt?
( Innodb_buffer_pool_bytes_data / innodb_buffer_pool_size ) = 4M / 10M = 40.0% -- Procent av buffertpoolen som tas upp av data-- En liten procent kan indikerar att buffertpoolen är onödigt stor.
( innodb_log_buffer_size / _ram ) = 16M / 1024M = 1.6% -- Procent av RAM som används för att buffra InnoDB-loggskrivningar.-- För stora tar bort från andra användningsområden för RAM.
( innodb_log_file_size * innodb_log_files_in_group / innodb_buffer_pool_size ) = 48M * 2 / 10M = 960.0% -- Förhållande mellan loggstorlek och buffertpoolstorlek. 50 % rekommenderas, men se andra beräkningar för om det spelar någon roll.-- Loggen behöver inte vara större än buffertpoolen.
( innodb_flush_method ) = innodb_flush_method = -- Hur InnoDB ska be OS att skriva block. Föreslå O_DIRECT eller O_ALL_DIRECT (Percona) för att undvika dubbelbuffring. (Åtminstone för Unix.) Se chrischandler för varning om O_ALL_DIRECT
( innodb_flush_neighbors ) = 1 -- En mindre optimering när man skriver block till disk.-- Använd 0 för SSD-enheter; 1 för hårddisk.
( innodb_io_capacity ) = 200 - I/O-operationer per sekund kan på disken. 100 för långsamma körningar; 200 för snurrande enheter; 1000-2000 för SSD-enheter; multiplicera med RAID-faktor.
( innodb_print_all_deadlocks ) = innodb_print_all_deadlocks = OFF -- Om du ska logga alla deadlocks.-- Om du plågas av deadlocks, slå på detta. Varning:Om du har många dödlägen kan detta skriva mycket till disken.
( min( tmp_table_size, max_heap_table_size ) / _ram ) = min( 16M, 16M ) / 1024M = 1.6% -- Procent av RAM att tilldela när man behöver MEMORY-tabell (per tabell), eller temp-tabell i en SELECT (per temp-tabell per vissa SELECT). För högt kan leda till utbyte.-- Minska tmp_table_size och max_heap_table_size till säg 1 % av ram.
( net_buffer_length / max_allowed_packet ) = 16,384 / 16M = 0.10%
( local_infile ) = local_infile = ON -- local_infile =PÅ är ett potentiellt säkerhetsproblem
( Select_scan / Com_select ) = 111,324 / 264144 = 42.1% -- % av de utvalda som gör full tabellskanning. (Kan luras av lagrade rutiner.) -- Lägg till index / optimera frågor
( long_query_time ) = 10 -- Cutoff (sekunder) för att definiera en "långsam" fråga.-- Föreslå 2
( Max_used_connections / max_connections ) = 152 / 151 = 100.7% -- Toppprocent av anslutningar - öka max_connections och/eller minska wait_timeout
Du har Frågecachen till hälften. Du bör ställa in både query_cache_type =OFF och query_cache_size =0 . Det finns (enligt ett rykte) en "bugg" i QC-koden som lämnar viss kod på om du inte stänger av båda dessa inställningar.
Onormalt liten:
( Innodb_pages_read + Innodb_pages_written ) / Uptime = 0.186
Created_tmp_files = 0.015 /HR
Handler_write = 0.21 /sec
Innodb_buffer_pool_bytes_data = 3 /sec
Innodb_buffer_pool_pages_data = 256
Innodb_buffer_pool_pages_total = 638
Key_reads+Key_writes + Innodb_pages_read+Innodb_pages_written+Innodb_dblwr_writes+Innodb_buffer_pool_pages_flushed = 0.25 /sec
Table_locks_immediate = 2.8 /HR
Table_open_cache_hits = 0.44 /sec
innodb_buffer_pool_chunk_size = 5MB
Onormalt stor:
Com_create_db = 0.41 /HR
Com_drop_db = 0.41 /HR
Connection_errors_peer_address = 2
Performance_schema_file_instances_lost = 9
Ssl_default_timeout = 500
Onormala strängar:
ft_boolean_syntax = + -><()~*:&
have_ssl = YES
have_symlink = DISABLED
innodb_fast_shutdown = 1
optimizer_trace = enabled=off,one_line=off
optimizer_trace_features = greedy_search=on, range_optimizer=on, dynamic_range=on, repeated_subselect=on
session_track_system_variables = time_zone, autocommit, character_set_client, character_set_results, character_set_connection
slave_rows_search_algorithms = TABLE_SCAN,INDEX_SCAN