Query demorando muito para retorno.

Você estas usando PDO ou mysql_query?

As tabelas tem índices ?

As estatísticas estão atualizadas ?

Fez o Plano de Execução da Query ?

Tentou unificar estes AND & OR numa condição só ?

As tabelas tem índices ?

As estatísticas estão atualizadas ?

Fez o Plano de Execução da Query ?

Tentou unificar estes AND & OR numa condição só ?

As tabelas tem índices ?

Sim

As estatísticas estão atualizadas ?

Não verifiquei. (Como se verifica ?)

Fez o Plano de Execução da Query ?

Não, como se faz?

Tentou unificar estes AND & OR numa condição só ?

R: não consegui deixar mais compacto para obter o resultado q preciso.

Estou usando Pdo

Estou usando PDO

Estas usando um servidor Local?

http://dev.mysql.com/doc/refman/5.0/en/explain.html

http://dev.mysql.com/doc/refman/5.0/en/analyze-table.html

http://dev.mysql.com/doc/refman/5.0/en/using-explain.html

http://dev.mysql.com/doc/refman/5.0/en/explain-extended.html

Não sei detalhes, conheço por analogia à outros BDs.

Quantos registros essa query retorna?

Sim ela está em um servidor local e dedicado.

Somente esta query está demorando.... as demais estão oks

Ela retorna 20 registros.

Sua primeira pergunta esta respondida...

>
Sim ela está em um servidor local e dedicado.

Somente esta query está demorando.... as demais estão oks

Ela retorna 20 registros.

>

Tem algo errado nela ?

Sim. :-)

O propósito da sua consulta me parece meio ambiguo. Você pode detalhar um pouco mais sobre os seus objetivos? Você já tem o resultado do EXPLAIN?

Você já fez a execução em partes para entender se é uma parte especifica que demora mais que outras? O EXPLAIN vai te dar essa resposta também.

Ficou um pouco longo mas ficou bem explicado (pelo menos creio eu!)

A tabela users_linked é onde está registro o tipo de ligação entre os usuários

A tabela user_profile é onde fica o cadastro do usuário.

A tabela post é onde fica a postagem do usuário.

Nesta minha pesquisa eu quero obter as postagens minha e dos usuários que eu tenho algum tipo de ligação.

Tabela users_linked:

id_link id_link - bigint(20)

id_user id_user - bigint(20)

Usuário que tem amizade com o id_user_linked

id_user_linked id_user_linked - bigint(20)

Usuário a quem se refere o link_status, visibility

link_status link_status - tinyint(3)

[0- aguardando autorização / 1 - aguardando resposta / 2 - autorizado / 3 -não autorizado]

link_type link_type - tinyint(3)

* 0 = sem conexão

* 1 = aguardando aprovação

* 2 = amigos

* 3 = seguindo.

on_feed on_feed - tinyint(3)

[0 não, 1 sim] padrão: 1 sim - mostrar ou não no feed do usuário

datetime_create datetime_create - timestamp

relationship relationship - tinyint(3)

Na tabela post o campo que ao meu ver é relevante para montar a query é o visibility que marcar o tipo de visibilidade da postagem (0 = todos, 1 = somente para amizades aceitas, 2 somente eu)

Detalhe, se eu tentar adicionar algum usuário, as suas postagens publicas automaticamente tem que ser retornada nesta "query problemática"

Nesta primeira condição eu postagens de usuários que aceitaram a amizade do usuário com id = 2

WHERE
(users_linked.id_user = 2
AND
users_linked.on_feed = 1
AND
users_linked.link_status = 2
AND
post.visibility IN (1,0)
AND timestamp <= FROM_UNIXTIME(1400261402))

Nesta aqui é verificado usuário que ainda nao decidiu aceitar o usuário id= 2 como amigo, sendo assim apenas as postagens publicas serão retornadas.

OR
(users_linked.id_user = 2
AND
users_linked.on_feed = 1
AND
users_linked.link_status = 0
AND
post.visibility=0

AND timestamp <= FROM_UNIXTIME(1400261402))
Por fim aqui é recebido as postagens do proprio usuário (id=2).

OR
(post.id_user = 2

AND timestamp <= FROM_UNIXTIME(1400261402))
Resultado do EXPLAIN:

{
"data":
[
{
"id": 1,
"select_type": "SIMPLE",
"table": "post",
"type": "range",
"possible_keys": "id_user,timestamp",
"key": "timestamp",
"key_len": "4",
"ref": null,
"rows": 5219,
"Extra": "Using where; Using temporary; Using filesort"
},
{
"id": 1,
"select_type": "SIMPLE",
"table": "user_profile",
"type": "eq_ref",
"possible_keys": "PRIMARY",
"key": "PRIMARY",
"key_len": "8",
"ref": "dhenee_dados.post.id_user",
"rows": 1,
"Extra": ""
},
{
"id": 1,
"select_type": "SIMPLE",
"table": "users_linked",
"type": "ref",
"possible_keys": "id_user_linked",
"key": "id_user_linked",
"key_len": "8",
"ref": "dhenee_dados.user_profile.id_user",
"rows": 4,
"Extra": "Using where"
}
]
}

experimente isolar a condição

users_linked.id_user = 2

tipo

SELECT
 `post`.`id_post`,
 `post`.`id_user`,
 `post`.`default_name`,
 `post`.`description`,
 `post`.`visibility`,
 `post`.`gmdate_ref`,
 `post`.`comment_count`,
 `post`.`approved_count`,
 `post`.`disapproved_count`,
 `post`.`location`,
 `post`.`timezone_offset`,
 `post`.`timezone_name`,
 `post`.`timestamp`,
 `user_profile`.`first_name`,
 `user_profile`.`last_name`,
 `user_profile`.`display_name`,
 `user_profile`.`photo`,
 `user_profile`.`url_profile`
 FROM
 `post`
 INNER JOIN `user_profile` ON `user_profile`.`id_user` = `post`.`id_user`
 LEFT JOIN `users_linked` ON `post`.`id_user` = `users_linked`.`id_user_linked`
 WHERE

AND timestamp <= FROM_UNIXTIME(1400261402))
OR
(`
users_linked.on_feed = 1
AND
users_linked.link_status = 0
AND
post.visibility=0

AND timestamp <= FROM_UNIXTIME(1400261402))
OR
(` timestamp <= FROM_UNIXTIME(1400261402))
)
GROUP BY
post.id_post
ORDER BY
timestamp DESC LIMIT 0,20
se houver um índice o otimizador pode vir a usá-lo.