нужно заставить индекс для выбора быть в состоянии работать быстрее? - PullRequest
Новая
       6

нужно заставить индекс для выбора быть в состоянии работать быстрее?

0 голосов
/ 07 мая 2018

У меня есть большой выбор, и когда я использую объяснение, это показывает:

enter image description here Мне нужно использовать force index, чтобы использовать (user) в качестве индекса (ключа) для таблицы PP.

После индекса силы он удалит пользователя (ключ) из таблицы pp2. поэтому мне нужно использовать индекс силы (user) и pp2.

После форсирования индекса для pp и pp2 таблица p будет автоматически использовать primary в качестве индекса, и все будет работать нормально.

Мой вопрос здесь, в чем проблема? почему mysql не использует в качестве ключа в таблице pp возможные_ключи user?

почему после того, как я заставлю pp использовать ключ user, он будет портиться с ключом на pp2? добавив ключ = ноль на нем. почему после принудительного использования pp и pp2 с использованием пользователя в качестве ключа таблица p будет использовать первичный в качестве ключа, и все будет работать нормально?

SQL: 

select c.nome, p.foto, c.user, p.user, p.id, p.data, p.titulo, p.youtube, pp.foto, count(DISTINCT likes.user) as likes_count, count(distinct comentarios.id) as comentarios_count, count(DISTINCT l2.user) as count2, 

linked.id as shared_id, linked.titulo as shared_titulo, linked.user as shared_user_id, c2.user as shared_nick, linked.foto as shared_foto, pp2.foto as shared_perfil,
count(DISTINCT share_count.id) as shares_count

from posts p 

join cadastro c on p.user=c.id 
left join profile_picture pp force index (user) on p.user = pp.user
left join likes on likes.post = p.id
left join comentarios on comentarios.foto = p.id and comentarios.delete = 0  
left join likes l2 on l2.post = p.id and l2.user = 1

left join posts linked on linked.id = p.post_share
left join cadastro c2 on linked.user=c2.id
left join profile_picture pp2 force index (user) on linked.user = pp2.user
left join posts share_count on share_count.post_share = p.id and share_count.delete=0

where (p.user in (select following from following where user =1 and block=0) or p.user=1) and p.delete=0
group by p.id
order by p.id desc limit 15

изображение профиля: 

CREATE TABLE `profile_picture` (
  `user` int(11) UNSIGNED NOT NULL,
  `foto` varchar(400) NOT NULL,
  UNIQUE KEY `user` (`user`)
) ENGINE=InnoDB ;

спасибо.

1 Ответ

0 голосов
/ 07 мая 2018

для повышения производительности вы также можете избежать предложения IN и использовать для этого внутреннее соединение, например: (я надеюсь) 

  select c.nome, p.foto, c.user, p.user, p.id, p.data, p.titulo, p.youtube, pp.foto, count(DISTINCT likes.user) as likes_count, count(distinct comentarios.id) as comentarios_count, count(DISTINCT l2.user) as count2, 

  linked.id as shared_id, linked.titulo as shared_titulo, linked.user as shared_user_id, c2.user as shared_nick, linked.foto as shared_foto, pp2.foto as shared_perfil,
  count(DISTINCT share_count.id) as shares_count

  from posts p 

  join cadastro c on p.user=c.id 
  left join profile_picture pp force index (user) on p.user = pp.user
  left join likes on likes.post = p.id
  left join comentarios on comentarios.foto = p.id and comentarios.delete = 0  
  left join likes l2 on l2.post = p.id and l2.user = 1

  left join posts linked on linked.id = p.post_share
  left join cadastro c2 on linked.user=c2.id
  left join profile_picture pp2 force index (user) on linked.user = pp2.user
  left join posts share_count on share_count.post_share = p.id and share_count.delete=0

  inner join following f on (f.following = p.user and f.user=1 and f.block = 0 and p.delete=0)  
      OR  ( p.user=1 and p.delete =0)

  group by p.id
  order by p.id desc limit 15

и, глядя на вашу таблицу pp, где у вас есть уникальный индекс пользователя, вы можете попробовать изменить это на условие pk в create 

  CREATE TABLE `profile_picture` (
    `user` int(11) UNSIGNED NOT NULL,
    `foto` varchar(400) NOT NULL,
   PRIMARY KEY   (`user`)
  ) ENGINE=InnoDB ;
...