Esta manhã, nosso aurora mysql serverless 2 disparou e basicamente travou. Temos um escritor/leitor e um leitor associado ao cluster.
No leitor, tivemos uma consulta de seleção intensa. Esta é a consulta que o RDS mostra (nomes dos campos alterados), a questão é que ela tem várias funções FIND_IN_SET e os insights mostram que examinou 109.826,50 linhas.
SELECIONE thisstuff
( thistime
) COMO thestuff
, CONTAR ( * ) COMO count
DE mytable
ONDE todo
= ? E someID
= ? E ( ( FIND_IN_SET
( otherID
, ? ) ) || ( ( FIND_IN_SET
( otherID
, ? ) ) || ( FIND_IN_SET
( otherID
, ? ) ) ) E ( thistime
ENTRE ? E ? ) E some_status
= ? Agrupar por months_todo
( thistime
)
Ao mesmo tempo, nosso escritor teve as seguintes esperas.
esperar/io/redo_log_flush
sincronização/sxlock/innodb/hash_table_locks
esperar/io/tabela/sql/handler
Alguém pode me ajudar a entender por que isso aconteceu, como o gravador bloqueou as tabelas ou o FIND_IN_SET bloqueou o gravador? O escritor estava fazendo atualizações na mesma tabela no momento em que a consulta estava acontecendo. Há uma maneira de prevenir isto?
Obrigado
Vamos tentar fazer com que a consulta seja executada mais rapidamente.
ajudaria.
Se os testes para otherID fossem valores únicos, isso não funcionaria tão bem (e mais rápido)?
Se existem listas, que tal
O que é
months_todo
? Se for uma função, vamos ver. Também parecethissstuff(...)
uma função; vamos ver isso.