Re Slowlog:Vis os din my.cnf. Var ændringerne i [mysqld] afsnit? Test det via SELECT SLEEP(12); , så kig både i filen og tabellen.
Alternativ måde at finde forespørgslen på:Da forespørgslen tager adskillige minutter, skal du SHOW FULL PROCESSLIST; når du tror, den kører.
Hvor meget RAM har du? Gør ikke har max_allowed_packet=300M medmindre du har mindst 30 GB RAM. Ellers risikerer du at bytte (eller endda gå ned). Hold denne indstilling under 1 % af RAM.
For yderligere analyse af tunables, angiv venligst (1) RAM-størrelse, (2) SHOW VARIABLES; og (3) SHOW GLOBAL STATUS; .
Re deleted_at :Det link du gav starter med "Kolonnen slettet_at er ikke en god indekskandidat". Du misforstod det. Det taler om en enkelt kolonne INDEX(deleted_at) . Jeg foreslår et sammensat indeks såsom INDEX(contact_id, job_class_name, execute_at, deleted_at) .
158 sekunder for en simpel forespørgsel på et lille bord? Det kan være, at der er meget andet ting, der foregår. Hent PROCESSLIST .
Ad separate indekser versus sammensatte:Tænk på to indekser:INDEX(last_name) og INDEX(first_name) . Du bladrer gennem efternavn-indekset for at finde "James", hvad kan du så gøre? At bladre gennem det andet indeks for "Rick" hjælper dig ikke med at finde mig.
Analyse af VARIABLER og GLOBAL STATUS
Observationer:
- Version:5.7.22-log
- 1,00 GB RAM
- Opetid =16d 10:30:19
- Er du sikker på, at dette var en VIS GLOBAL STATUS?
- Du kører ikke på Windows.
- Kører 64-bit version
- Du ser ud til at køre helt (eller for det meste) InnoDB.
De mere vigtige problemer:
innodb_buffer_pool_size -- jeg troede du havde den på 213M, ikke 10M. 10M er alt for lille. På den anden side ser du ud til at du har mindre end så meget data.
Da RAM'en er så lille, anbefaler jeg at droppe tmp_table_size og max_heap_table_size og max_allowed_packet til 8M. Og sænk table_open_cache, table_definition_cache og innodb_open_files til 500.
Hvad forårsager så mange samtidige forbindelser?
Detaljer og andre observationer:
( innodb_buffer_pool_size / _ram ) = 10M / 1024M = 0.98% -- % af RAM brugt til InnoDB buffer_pool
( innodb_buffer_pool_size ) = 10M -- InnoDB Data + Index cache
( innodb_lru_scan_depth ) = 1,024 -- "InnoDB:page_cleaner:1000ms beregnet løkke tog ..." kan rettes ved at sænke lru_scan_depth
( Innodb_buffer_pool_pages_free / Innodb_buffer_pool_pages_total ) = 375 / 638 = 58.8% -- Pct af buffer_pool er ikke i brug i øjeblikket - innodb_buffer_pool_size er større end nødvendigt?
( Innodb_buffer_pool_bytes_data / innodb_buffer_pool_size ) = 4M / 10M = 40.0% -- Procent af bufferpuljen optaget af data - En lille procent kan angive, at buffer_poolen er unødvendigt stor.
( innodb_log_buffer_size / _ram ) = 16M / 1024M = 1.6% -- Procent af RAM brugt til buffering af InnoDB-logskrivninger.-- For stor fjernelse fra andre anvendelser af RAM.
( innodb_log_file_size * innodb_log_files_in_group / innodb_buffer_pool_size ) = 48M * 2 / 10M = 960.0% -- Forholdet mellem logstørrelse og buffer_pool-størrelse. 50% anbefales, men se andre beregninger for om det har betydning.-- Loggen behøver ikke at være større end bufferpuljen.
( innodb_flush_method ) = innodb_flush_method = -- Hvordan InnoDB skal bede operativsystemet om at skrive blokke. Foreslå O_DIRECT eller O_ALL_DIRECT (Percona) for at undgå dobbelt buffering. (I hvert fald for Unix.) Se chrischandler for advarsel om O_ALL_DIRECT
( innodb_flush_neighbors ) = 1 -- En mindre optimering ved skrivning af blokke til disk. -- Brug 0 til SSD-drev; 1 til HDD.
( innodb_io_capacity ) = 200 - Mulighed for I/O-operationer pr. sekund på disk. 100 for langsomme drev; 200,- for roterende drev; 1000-2000 for SSD'er; gange med RAID-faktor.
( innodb_print_all_deadlocks ) = innodb_print_all_deadlocks = OFF -- Om alle deadlocks skal logges.-- Hvis du er plaget med deadlocks, så slå dette til. Forsigtig:Hvis du har mange deadlocks, kan dette skrive meget til disken.
( min( tmp_table_size, max_heap_table_size ) / _ram ) = min( 16M, 16M ) / 1024M = 1.6% -- Procent af RAM, der skal tildeles, når der er brug for MEMORY-tabel (pr. tabel), eller midlertidig tabel inde i en SELECT (pr. temp-tabel pr. nogle SELECTs). For høj kan føre til ombytning.-- Reducer tmp_table_size og max_heap_table_size til f.eks. 1 % af ram.
( net_buffer_length / max_allowed_packet ) = 16,384 / 16M = 0.10%
( local_infile ) = local_infile = ON -- local_infile =TIL er et potentielt sikkerhedsproblem
( Select_scan / Com_select ) = 111,324 / 264144 = 42.1% -- % af udvalgte, der laver fuld tabelscanning. (Kan blive narre af lagrede rutiner.)-- Tilføj indekser / optimer forespørgsler
( long_query_time ) = 10 -- Cutoff (sekunder) for at definere en "langsom" forespørgsel.-- Foreslå 2
( Max_used_connections / max_connections ) = 152 / 151 = 100.7% -- Peak % af forbindelser -- øg max_connections og/eller reducer wait_timeout
Du har forespørgselscachen halveret. Du bør indstille både query_cache_type =OFF og query_cache_size =0 . Der er (ifølge et rygte) en 'bug' i QC-koden, der efterlader noget kode aktiveret, medmindre du slår begge disse indstillinger fra.
Unormalt lille:
( 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
Unormalt 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
Unormale strenge:
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