Trabalho com um servidor não gerenciado em um datacenter remoto para hospedar aplicativos baseados na web. Quando executamos os scripts SQL para criar e preencher um banco de dados de aplicativos, todo o processo é dolorosamente lento. Um conjunto de scripts que no meu PC local com pouca potência é executado em 5 segundos , no servidor remoto pode levar até 20 minutos .
Quando verifico os processos em execução, vejo que não está preso em nenhuma instrução específica, é simplesmente que cada um leva vários segundos, especialmente ALTER TABLE
instruções:
ALTER TABLE foo_bar
ADD CONSTRAINT FK_foo_bar_foo_id
FOREIGN KEY (foo_id)
REFERENCES foo (id)
É um aplicativo totalmente novo, então a maioria das tabelas está vazia ou tem no máximo algumas centenas de linhas. Mas a lentidão já acontece muito antes das INSERT INTO
declarações. Todas as tabelas são InnoDB.
Eu corro os scripts através do PHP de linha de comando, se isso importa. Não há antivírus que eu conheça. O MySQL/8.0 foi instalado com o Windows MySQL Installer e funciona como serviço com esta configuração:
[client]
port=3306
[mysql]
no-beep
[mysqld]
port=3306
datadir=C:/ProgramData/MySQL/MySQL Server 8.0/Data
default_authentication_plugin=mysql_native_password
default-storage-engine=INNODB
sql-mode="STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION"
log-output=FILE
general-log=0
general_log_file="FOO.log"
slow-query-log=1
slow_query_log_file="FOO-slow.log"
long_query_time=10
log-error="FOO.err"
server-id=1
lower_case_table_names=1
secure-file-priv="C:/ProgramData/MySQL/MySQL Server 8.0/Uploads"
max_connections=151
table_open_cache=2000
tmp_table_size=16M
thread_cache_size=10
myisam_max_sort_file_size=100G
myisam_sort_buffer_size=8M
key_buffer_size=8M
read_buffer_size=0
read_rnd_buffer_size=0
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=1M
innodb_buffer_pool_size=8M
innodb_log_file_size=48M
innodb_thread_concurrency=17
innodb_autoextend_increment=64
innodb_buffer_pool_instances=8
innodb_concurrency_tickets=5000
innodb_old_blocks_time=1000
innodb_open_files=300
innodb_stats_on_metadata=0
innodb_file_per_table=1
innodb_checksum_algorithm=0
back_log=80
flush_time=0
join_buffer_size=256K
max_allowed_packet=4M
max_connect_errors=100
open_files_limit=4161
sort_buffer_size=256K
table_definition_cache=1400
binlog_row_event_max_size=8K
sync_master_info=10000
sync_relay_log=10000
sync_relay_log_info=10000
loose_mysqlx_port=33060
character-set-server = utf8
collation-server = utf8_unicode_ci
log-bin = OFF
skip-bin-log
Por onde posso começar a ver isso? Que diagnósticos posso tentar?
Qual versão cada servidor está usando?
ALTER TABLE
tornou-se significativamente mais lento em 8.0. Provavelmente tem a ver com a capacidade de reverter DDLs.Nunca foi sábio depender de muitos DDLs, mas isso torna as coisas piores.
Se isso
ALTER
estivesse sendo feito em uma tabela totalmente nova, provavelmente teria sido melhor incluir oCONSTRAINT
como parte da definição da tabela. Claro, se oALTER
foi gerado pelo mysqldump`, isso não é prático. Além disso, os FKs são muito exigentes quanto ao pedido, então você pode ficar preso.Os nomes de arquivo em sua configuração NÃO devem estar entre aspas. Nunca vi ninguém rodar com read_buffer_size e read_rnd_buffer_size=0. Desative essas duas linhas liderando a linha com # e um caractere de espaço para permitir que os padrões funcionem para você.