Re Slowlog:Mostre-nos seu my.cnf. As mudanças no
[mysqld] seção? Teste via SELECT SLEEP(12); , em seguida, procure no arquivo e na tabela. Maneira alternativa de encontrar a consulta:Como a consulta está demorando vários minutos, faça
SHOW FULL PROCESSLIST; quando você acha que pode estar em execução. Quanta memória RAM você tem? não tem
max_allowed_packet=300M a menos que você tenha pelo menos 30 GB de RAM. Caso contrário, você corre o risco de trocar (ou até mesmo travar). Mantenha essa configuração abaixo de 1% de RAM. Para uma análise mais detalhada de ajustáveis, forneça (1) tamanho de RAM, (2)
SHOW VARIABLES; e (3) SHOW GLOBAL STATUS; . Re
deleted_at :Esse link que você deu começa com "A coluna delete_at não é um bom candidato ao índice". Você interpretou mal. Ele está falando sobre um INDEX(deleted_at) de coluna única . Estou sugerindo um índice composto como INDEX(contact_id, job_class_name, execute_at, deleted_at) . 158 segundos para uma consulta simples em uma mesa pequena? Pode ser que haja muitos outros coisas acontecendo. Obtenha a
PROCESSLIST . Re Índices separados versus compostos:Pense em dois índices:
INDEX(last_name) e INDEX(first_name) . Você percorre o índice last_name para encontrar "James", então o que você pode fazer? Folhear o outro índice de "Rick" não ajudará você a me encontrar. Análise de VARIÁVEIS e STATUS GLOBAL
Observações:
- Versão:5.7.22-log
- 1,00 GB de RAM
- Tempo de atividade =16d 10:30:19
- Tem certeza de que este foi um SHOW GLOBAL STATUS?
- Você não está executando no Windows.
- Executando a versão de 64 bits
- Você parece estar executando inteiramente (ou principalmente) o InnoDB.
Os problemas mais importantes:
innodb_buffer_pool_size -- Eu pensei que você tinha 213M, não 10M. 10M é muito pequeno. Por outro lado, você parece ter menos do que essa quantidade de dados.
Como a RAM é muito pequena, recomendo descartar tmp_table_size e max_heap_table_size e max_allowed_packet para 8M.And lower table_open_cache, table_definition_cache e innodb_open_files para 500.
O que causa tantas conexões simultâneas?
Detalhes e outras observações:
( innodb_buffer_pool_size / _ram ) = 10M / 1024M = 0.98% -- % de RAM usada para buffer_pool do InnoDB ( innodb_buffer_pool_size ) = 10M -- InnoDB Data + cache de índice ( innodb_lru_scan_depth ) = 1,024 -- "InnoDB:page_cleaner:1000ms de loop pretendido..." pode ser corrigido diminuindo lru_scan_depth ( Innodb_buffer_pool_pages_free / Innodb_buffer_pool_pages_total ) = 375 / 638 = 58.8% -- Porcentagem de buffer_pool atualmente não em uso -- innodb_buffer_pool_size é maior que o necessário? ( Innodb_buffer_pool_bytes_data / innodb_buffer_pool_size ) = 4M / 10M = 40.0% -- Porcentagem do buffer pool ocupado por dados -- Uma pequena porcentagem pode indicam que o buffer_pool é desnecessariamente grande. ( innodb_log_buffer_size / _ram ) = 16M / 1024M = 1.6% -- Porcentagem de RAM usada para armazenar em buffer gravações de log do InnoDB. -- Muito grande tira outros usos da RAM. ( innodb_log_file_size * innodb_log_files_in_group / innodb_buffer_pool_size ) = 48M * 2 / 10M = 960.0% -- Proporção do tamanho do log para o tamanho do buffer_pool. 50% é recomendado, mas veja outros cálculos para saber se isso importa.-- O log não precisa ser maior que o buffer pool. ( innodb_flush_method ) = innodb_flush_method = -- Como o InnoDB deve pedir ao SO para escrever blocos. Sugira O_DIRECT ou O_ALL_DIRECT (Percona) para evitar buffer duplo. (Pelo menos para Unix.) Veja chrischandler para advertência sobre O_ALL_DIRECT ( innodb_flush_neighbors ) = 1 -- Uma pequena otimização ao gravar blocos no disco. -- Use 0 para unidades SSD; 1 para HD. ( innodb_io_capacity ) = 200 -- Capacidade de operações de E/S por segundo no disco . 100 para unidades lentas; 200 para acionamentos giratórios; 1000-2000 para SSDs; multiplicar pelo fator RAID. ( innodb_print_all_deadlocks ) = innodb_print_all_deadlocks = OFF -- Se deve registrar todos os Deadlocks.-- Se você estiver atormentado com Deadlocks, ative esta opção. Cuidado:Se você tiver muitos deadlocks, isso pode gravar muito no disco. ( min( tmp_table_size, max_heap_table_size ) / _ram ) = min( 16M, 16M ) / 1024M = 1.6% -- Porcentagem de RAM a ser alocada ao precisar de uma tabela MEMORY (por tabela) ou tabela temporária dentro de um SELECT (por tabela temporária por alguns SELECTs). Muito alto pode levar à troca.-- Diminua tmp_table_size e max_heap_table_size para, digamos, 1% da ram. ( net_buffer_length / max_allowed_packet ) = 16,384 / 16M = 0.10% ( local_infile ) = local_infile = ON -- local_infile =ON é um possível problema de segurança ( Select_scan / Com_select ) = 111,324 / 264144 = 42.1% -- % de seleções fazendo varredura completa da tabela. (Pode ser enganado por rotinas armazenadas.) -- Adicionar índices/otimizar consultas ( long_query_time ) = 10 -- Corte (segundos) para definir uma consulta "lenta". -- Sugestão 2 ( Max_used_connections / max_connections ) = 152 / 151 = 100.7% -- Pico % de conexões -- aumenta max_connections e/ou diminui wait_timeout Você tem o Cache de Consulta pela metade. Você deve definir query_cache_type =OFF e query_cache_size =0 . Há (de acordo com um boato) um 'bug' no código QC que deixa algum código ativado, a menos que você desative ambas as configurações.
Anormalmente pequeno:
( 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
Anormalmente grande:
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
Cordas anormais:
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
