какие у меня варианты, так как мой mysql DB растет

Question

Как я могу улучшить этот запрос? Пожалуйста скажите мне все мои варианты здесь моей социальной сети DB только становится больше

Этот запрос занял 2.1231 сек

SELECT friend_friend.friendid, friend_reg_user.disp_name, friend_reg_user.pic_url, friend_reg_user.online 
FROM friend_friend 
INNER JOIN friend_reg_user ON friend_friend.friendid = friend_reg_user.auto_id 
WHERE userid =1 
AND friend_friend.status =1 
ORDER BY autoid DESC 
LIMIT 59535 , 15 


##################################################################################################################################### 
# id # select_type # table   # type # possible_keys # key  # key_len # ref      # rows # Extra  # 
##################################################################################################################################### 
# 1 # SIMPLE  # friend_friend # ref  # userid  # userid # 5  # const     # 59843 # Using where# 
# 1 # SIMPLE  # friend_reg_user # eq_ref # PRIMARY  # PRIMARY # 4  # friend_friend.friendid # 1  #   # 
##################################################################################################################################### 

Каковы мои варианты, когда эта таблица говорят миллион или даже 2 миллиона строк большой? Эта таблица используется, чтобы определить, кто является пользователем друзей.

Answer 1

Я знаю программиста, который работает с 8 миллионами записей в своей базе данных, и это действительно не сильно меняет скорость. Речь идет только о создании правильных индексов и обеспечении того, чтобы вы эффективно брали данные. (Числовые идентификаторы для отношений действительно полезны)

Кроме того, ваш запрос по сути является баребонами по большей части. Ничего особенного. Это может быть просто латентность вашего сервера.

Answer 2

Возможно, я действительно не понимаю вашу схему, но вам действительно нужен LEFT JOIN? Не могли бы вы использовать INNER JOIN?

(Я часто слышал, что может быть лучше для выступлений, поскольку он возвращает меньше строк, в вашем случае, если вы хотите друзей одного парня, я не вижу смысла в левом соединении: друзья будут «связаны», и, таким образом, есть запись в «связывающей» таблицы, нет)

Кроме того, убедитесь, что у вас есть индексы на полях, используемых:

• в условиях (либо «где» или «присоединяться»); Кажется, здесь хорошо?
• для сортировки; У autoid есть индекс?

MySQL используется с действительно большими таблицами в некоторых приложениях и может очень быстро реагировать, если индексы/конфигурация в порядке; так что есть определенно то, что мы должны здесь сделать ;-)

В качестве побочного элемента: вы префиксеруете почти все имена полей по имени таблицы (из-за дубликатов в именах полей, я полагаю) ; почему бы вам не всегда сделать это? Это сделало бы запрос немного легче понять ;-)

Answer 3

До тех пор, пока столбцы в вашем предложении WHERE являются индексами, вы должны быть в порядке. Я бы сгенерировал набор тестовых данных и выполнил некоторые тесты.

Кроме того, что еще более важно, ознакомьтесь с синтаксисом MySQL's EXPLAIN. Это поможет вам определить, сколько строк действительно используется в запросе (среди прочего), и является отличным инструментом для оптимизации запросов и табличных индексов.

Answer 4

Вы должны узнать, что вызывает его замедление.

Подходит ли ваша база данных в памяти? Если нет, получите больше - нет, действительно. Диск медленный, как бы вы ни смотрели на него.

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

На практике это означает определенную степень денормализации (вам действительно нужно присоединиться?Не можете ли вы сохранить (копии) все необходимые поля в таблице xref?) И разумное использование индексов покрытия.

В InnoDB (предположим, вы используете Innodb здесь), первичный ключ сгруппирован. Это означает, что запросы, которые используют первичный ключ, занимают меньше IO, чем другие индексы (поскольку индекс хранится с данными на тех же страницах), потому что им не нужно делать потенциально отдельный IO для каждой строки, что часто требуется для вторичного индекса.

Основной принцип:

1. Воспроизведите проблему использования производственных-уровней данных о производственно-спецификации аппаратного обеспечения в непроизводственной среде
2. Диагностировать, что является причиной его
3. Сделать изменение, которое вы думаете, это может исправить.
4. Снова повторите попытку, используя ту же производственную среду производственной спецификации, чтобы проверить эффективность вашего исправления.
5. Повторяйте до тех пор, пока вы получили достаточную производительность, чтобы решить эту проблему (умиротворить своих клиентов и т.д.)

И в случае успеха, вы можете делать все, что обычную процедуру QA (например, регрессионного тестирования и т.д.), чтобы освободить изменение.

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