PRIMARY KEY на таблиці bb_bt_dlstatus

[yukoff]

Судячи з запитів, тут ефективнішим буде інший PK, наприклад

SELECT DISTINCT dl.user_id, u.user_opt, tr.user_id as active_dl
FROM bb_bt_dlstatus dl
LEFT JOIN bb_users u  ON(u.user_id = dl.user_id)
LEFT JOIN bb_bt_tracker tr ON(tr.user_id = dl.user_id)
WHERE dl.topic_id = ?
        AND dl.user_status IN (1, 0)
        AND dl.user_id NOT IN (...)
        AND u.user_active = 1
GROUP BY dl.user_id;

тут topic_id статичний, а для user_id використовується сканування діапазону (не зовсім так, бо не BETWEEN та не <, > тощо - тут т.зв. діапазон рівності, або equality range), тобто ефективніше буде PRIMARY KEY (topic_id, user_id), а не поточний (topic_id, user_id) - через специфіку роботи мускуля з діапазонами на композитних індексах (якщо я все правильно пригадую).

[yukoff]

Хоча судячи з explain-ів великої різниці немає, принаймні для цього запиту та на малій кількості даних - explain при поточному PK (sqlfiddle):

id	select_type	table	type	possible_keys	key	key_len	ref	rows	filtered	Extra
1	SIMPLE	dl	index	PRIMARY,topic_id	PRIMARY	6		10	60.00	Using where
1	SIMPLE	u	eq_ref	PRIMARY	PRIMARY	3	db_9_ba7276.dl.user_id	1	100.00	Using where
1	SIMPLE	tr	ref	user_id	user_id	3	db_9_ba7276.dl.user_id	1	100.00	Using index

та explain зі зміненим порядком стовпців (sqlfiddle):

id	select_type	table	type	possible_keys	key	key_len	ref	rows	filtered	Extra
1	SIMPLE	dl	index	PRIMARY,user_id	PRIMARY	6		10	60.00	Using where
1	SIMPLE	u	eq_ref	PRIMARY	PRIMARY	3	db_9_7448d0.dl.user_id	1	100.00	Using where
1	SIMPLE	tr	ref	user_id	user_id	3	db_9_7448d0.dl.user_id	1	100.00	Using index

Взагалі по базі оптимізацію треба буде робити спираючись на slow query log (до речі, там зараз щось є?).