Il nostro team ha appena trascorso il debug della scorsa settimana e ha cercato di trovare la fonte di molti timeout del blocco mysql e di molte query estremamente lunghe. Alla fine sembra che questa query sia il colpevole.Perché questa query causa il blocco dei timeout di attesa?
mysql> explain
SELECT categories.name AS cat_name,
COUNT(distinct items.id) AS category_count
FROM `items`
INNER JOIN `categories` ON `categories`.`id` = `items`.`category_id`
WHERE `items`.`state` IN ('listed', 'reserved')
AND (items.category_id IS NOT NULL)
GROUP BY categories.name
ORDER BY category_count DESC
LIMIT 10\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: items
type: range
possible_keys: index_items_on_category_id,index_items_on_state
key: index_items_on_category_id
key_len: 5
ref: NULL
rows: 119371
Extra: Using where; Using temporary; Using filesort
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
table: categories
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: production_db.items.category_id
rows: 1
Extra:
2 rows in set (0.00 sec)
posso vedere che si sta facendo una scansione di tabella brutto e la creazione di una tabella temporanea per l'esecuzione.
Perché questa query causerebbe tempi di risposta del database di un fattore dieci e alcune query che in genere richiedono 40-50 ms (aggiornamenti sulla tabella degli articoli), per esplodere a 50.000 ms o più a volte?
Hai provato profiling * senza * 'distinct'? Ci vuole un bel po 'di lavoro per farlo e si ha un bel po' le righe per filtrare troppo :) – PhD
Very nice. No, non l'ha fatto. Aiuta sicuramente a ottimizzarlo. Non è ancora chiaro perché una query lenta come questa può causare tanti problemi per noi. – chrishomer
chiedo solo perché avete bisogno di questo 'E (items.category_id non è nullo)' - in quanto si tratta di un JOIN' 'INTERNO - è category.id permesso di essere' null' –