mysql не использует primary

[Kirill]

mysql не использует primary

запрос:

SELECT 
DISTINCT 
a.id, a.name, a.main_text, a.phone, a.balance, a.id_unactive 
FROM 
pref_announcement a 
INNER JOIN pref_announcement_cities c ON a.id=c.id_announcement 
INNER JOIN pref_users u ON a.id_user=u.id 
INNER JOIN pref_partners p ON u.id_partner=p.id 
WHERE 
MATCH(a.main_text) AGAINST ('"объявления брянкс"' IN BOOLEAN MODE) 
AND a.is_offer='1'
AND c.id_city IN (2) 
AND a.visible=1 
AND a.is_active=1 
AND a.balance>0 
AND a.is_modering=1 
AND u.visible=1 
AND u.user_active=1 
AND p.visible=1

EXPLAIN данного запроса:
+----+-------------+-------+----------+------------------+-----------------+---------+----------------------+------+-----------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+----------+------------------+-----------------+---------+----------------------+------+-----------------------+
| 1 | SIMPLE | p | system | PRIMARY | NULL | NULL | NULL | 1 | Using temporary |
| 1 | SIMPLE | a | fulltext | PRIMARY,fulltext | fulltext | 0 | | 1 | Using where |
| 1 | SIMPLE | c | ref | id_announcement | id_announcement | 4 | mir_portal.a.id | 1 | Using where; Distinct |
| 1 | SIMPLE | u | eq_ref | PRIMARY | PRIMARY | 4 | mir_portal.a.id_user | 1 | Using where; Distinct |
+----+-------------+-------+----------+------------------+-----------------+---------+----------------------+------+-----------------------+

Почему таблица p (pref_partners) не использует первичный ключ, хотя у неё есть такой ключ?
show index from pref_partners;
+--------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+--------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| mir_partners | 0 | PRIMARY | 1 | id | A | 1 | NULL | NULL | | BTREE | |
| mir_partners | 0 | login | 1 | login | A | 1 | NULL | NULL | | BTREE | |
| mir_partners | 0 | email | 1 | email | A | 1 | NULL | NULL | | BTREE | |
+--------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+

буду благодарен если кто укажет на явные ошибки в запросе, из-за которых возможны тормоза, предполагается что таблица pref_announcement будет очень большой (порядка 1000000 записей).

 

[Wicked]

mysql в данном случае не видит смысла в использовании этого primary. Да и я тоже

PS: чтобы получить более реальный explain, добавь больше записей, чтобы избавиться от "system"-выборок.

 

[Kirill]

Добавил строки в таблицу pref_partners(всего 5 строк), теперь оператор explain выдает следующий результат;
+----+-------------+-------+----------+------------------+-----------------+---------+-------------------------+------+------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+----------+------------------+-----------------+---------+-------------------------+------+------------------------------+
| 1 | SIMPLE | a | fulltext | PRIMARY,fulltext | fulltext | 0 | | 1 | Using where; Using temporary |
| 1 | SIMPLE | c | ref | id_announcement | id_announcement | 4 | mir_portal.a.id | 1 | Using where; Distinct |
| 1 | SIMPLE | u | eq_ref | PRIMARY | PRIMARY | 4 | mir_portal.a.id_user | 1 | Using where; Distinct |
| 1 | SIMPLE | p | eq_ref | PRIMARY | PRIMARY | 4 | mir_portal.u.id_partner | 1 | Using where; Distinct |
+----+-------------+-------+----------+------------------+-----------------+---------+-------------------------+------+------------------------------+

Тревожит только тип соединения fulltext (хотя без него никак). Кто-нибудь видит какие-нибудь явные недочеты, которые скажутся при большом объеме таблицы? Как можно сейчас протестировать производительность, кроме как запихать в таблицы большое число строк?

-~{}~ 24.07.06 18:55:

еще вопрос, почему в таблицах u и p в графе возможных ключей указан только примари, хотя в выражении where есть условие
AND u.visible=1
AND u.user_active=1
AND p.visible=1
Поля visible и user_active являются tyniint(1). Индексы на них не созданы, да и нужны ли, если они все-равно не будут использоваться?

 

[Wicked]

поэкспериментируй с составными индексами, возможно эти поля тоже удастся задействовать.

Индексы на них не созданы

- именно поэтому

в таблицах u и p в графе возможных ключей указан только примари