Nano Hash - криптовалюты, майнинг, программирование

Улучшите производительность с помощью LEFT JOIN

У меня есть запрос mysql, который имеет 5 или 6 ЛЕВЫХ СОЕДИНЕНИЙ. Как и ожидалось, это довольно медленно. Учитывая, что я ожидаю только ~ 100 результатов, может быть, для меня имеет больше смысла запускать множество отдельных запросов sql и вручную сшивать их вместе. Я предполагаю, что это занимает много времени из-за огромной таблицы, созданной с несколькими левыми соединениями. Это правильно?

Я делаю это в Rails 3. Я знаю, что создание активных записей стоит дорого, но я полагаю, что это может быть быстрее, чем иметь так много ЛЕВЫХ СОЕДИНЕНИЙ. Я очень мало знаю о том, как база данных работает под капотом. Был бы очень признателен за любые идеи.


Изменить: вот фактические схемы запросов и таблиц.

Запрос

SELECT people.* FROM people LEFT JOIN person_organization_relationships ON person_organization_relationships.person_id = people.id AND person_organization_relationships.stop_person IS NULL LEFT JOIN person_redirect_relationships AS r_from_others ON r_from_others.parent_id = people.id AND r_from_others.stop_person IS NULL LEFT JOIN person_redirect_relationships AS r_to_others ON.r_to_others. child_id = people.id AND r_to_others.stop_person IS NULL LEFT JOIN person_organization_relationships AS r_p_check ON r_p_check.person_id = r_from_others.child_id AND r_p_check.stop_person IS NULL LEFT JOIN organization_redirect_relationships AS r_o_check ON r_o_check.child_idtop = person_organization_relationships.organization JOIN person_organization_relationships AS rr_p_check ON rr_p_check.person_id = r_from_others.child_id AND rr_p_check.stop_person IS NULL LEFT JOIN organization_redirect_relationships AS rr_o_check ON rr_p_check.organization_id = rr_o_check.child_id AND rr_o_check.stop_organization IS NULL WHERE (((_parentperson_organization_relationships16person_organization_relationships1) = 1) AND r_to_others.parent_id IS NULL) OR (r_p_check.organization_id = 1 OR rr_o_check.parent_id = 1)) GROUP BY people.id

Схема таблицы:

  create_table "people", :force => true do |t|
    t.datetime "created_at"
    t.datetime "updated_at"
    t.boolean  "delta",             :default => true, :null => false
  end


  create_table "person_organization_relationships", :force => true do |t|
    t.integer  "person_id"
    t.integer  "organization_id"
    t.integer  "start_person"
    t.integer  "stop_person"
    t.datetime "created_at"
    t.datetime "updated_at"
  end

  add_index "person_organization_relationships", ["organization_id"], :name => "index_person_organization_relationships_on_organization_id"
  add_index "person_organization_relationships", ["person_id"], :name => "index_person_organization_relationships_on_person_id"
  add_index "person_organization_relationships", ["start_person"], :name => "index_person_organization_relationships_on_start_person"
  add_index "person_organization_relationships", ["stop_person"], :name => "index_person_organization_relationships_on_stop_person"

  create_table "person_redirect_relationships", :force => true do |t|
    t.integer  "parent_id"
    t.integer  "child_id"
    t.integer  "start_person"
    t.integer  "stop_person"
    t.datetime "created_at"
    t.datetime "updated_at"
  end

  add_index "person_redirect_relationships", ["child_id"], :name => "index_person_redirect_relationships_on_child_id"
  add_index "person_redirect_relationships", ["parent_id"], :name => "index_person_redirect_relationships_on_parent_id"
  add_index "person_redirect_relationships", ["start_person"], :name => "index_person_redirect_relationships_on_start_person"
  add_index "person_redirect_relationships", ["stop_person"], :name => "index_person_redirect_relationships_on_stop_person"


  create_table "organization_redirect_relationships", :force => true do |t|
    t.integer  "parent_id"
    t.integer  "child_id"
    t.integer  "start_organization"
    t.integer  "stop_organization"
    t.datetime "created_at"
    t.datetime "updated_at"
  end

  add_index "organization_redirect_relationships", ["child_id"], :name => "index_organization_redirect_relationships_on_child_id"
  add_index "organization_redirect_relationships", ["parent_id"], :name => "index_organization_redirect_relationships_on_parent_id"
  add_index "organization_redirect_relationships", ["start_organization"], :name => "index_organization_redirect_relationships_on_start_organization"
  add_index "organization_redirect_relationships", ["stop_organization"], :name => "index_organization_redirect_relationships_on_stop_organization"

Этот запрос не дал результатов.

Но когда я выполнил запрос, это заняло 0,14 секунды. Это большой срок? Я пытаюсь выяснить, есть ли у меня хорошие запросы, прежде чем внедрять memcached.

Так много JOIN может быть очень плохой идеей, но сначала вы должны показать свой запрос.


  • Я согласен с @JoeStefanelli. Покажите нам запрос + результат _1_. 27.10.2011
  • Хороший ответ, я просто хочу подчеркнуть, что неправильное использование индексов является наиболее вероятной причиной плохой производительности в сценариях такого типа. 27.10.2011

Ответы:


1

Прежде всего, индексы необходимы для ускорения выполнения запроса. Если у вас их нет, вам, вероятно, следует создать их (в зависимости от выполняемого вами запроса).

И если вы делаете несколько LEFT JOIN, то вы могли бы (вероятно) разделить их на разные запросы, и это должно заставить приложение работать намного быстрее.

Вы можете обратиться к документации MySQL по оптимизации, в частности оптимизация левого соединения и оптимизация с использованием индексов. Это может дать вам дополнительную информацию.

Для этого может быть ряд причин. Низкая производительность запросов, плохие индексы и т. д. Операторы объяснения, запроса и, возможно, даже создания таблиц для рассматриваемых таблиц очень помогли бы найти ответ.

26.10.2011
  • +----+--------------+------------------------------ -----+--------+----------------------------------- -------------------------------------------------- ------------------+---------------- ---------------------------------------+---------+ -------------------------------------------------- ----------------------+------+------ -------------+ | идентификатор | тип_выбора | стол | тип | возможные_ключи
    | ключ | key_len | ссылка
    | строки | Экстра | +----+--------------+------------------------------ -----+--------+----------------------------------- -------------------------------------------------- ------------------+---------------- ---------------------------------------+---------+ -------------------------------------------------- ----------------------+------+------ -------------+ | 1 | ПРОСТО | человек_детали | ВСЕ | index_person_details_on_current_p_id
    | НУЛЕВОЙ | НУЛЕВОЙ | НУЛЕВОЕ
    | 4938 | Использование временного; Использование сортировки файлов | | 1 | ПРОСТО | люди | eq_ref | ОСНОВНОЙ
    | ОСНОВНОЙ | 4 | knolcano_development.person_details.current_p_id
    | 1 | | | 1 | ПРОСТО | person_organization_relationships | ссылка | index_person_organization_relationships_on_person_id,index_person_organization_relationships_on_stop_person | index_person_organization_relationships_on_person_id | 5 | knolcano_development.person_details.current_p_id
    | 1 | | | 1 | ПРОСТО | r_from_others | ссылка | index_person_redirect_relationships_on_parent_id,index_person_redirect_relationships_on_stop_person | index_person_redirect_relationships_on_stop_person | 5 | константа
    | 3 | | | 1 | ПРОСТО | r_to_others | ссылка | index_person_redirect_relationships_on_child_id,index_person_redirect_relationships_on_stop_person | index_person_redirect_relationships_on_child_id | 5 | knolcano_development.people.id
    | 2 | | | 1 | ПРОСТО | r_p_check | ссылка | index_person_organization_relationships_on_person_id,index_person_organization_relationships_on_stop_person | index_person_organization_relationships_on_person_id | 5 | knolcano_development.r_from_others.child_id
    | 1 | | | 1 | ПРОСТО | р_о_чек | ссылка | index_organization_redirect_relationships_on_child_id,index_organization_redirect_relationships_on_stop_organization | index_organization_redirect_relationships_on_child_id | 5 | knolcano_development.person_organization_relationships.organization_id | 1 | | | 1 | ПРОСТО | rr_p_check | ссылка | index_person_organization_relationships_on_person_id,index_person_organization_relationships_on_stop_person | index_person_organization_relationships_on_person_id | 5 | knolcano_development.r_from_others.child_id
    | 1 | | | 1 | ПРОСТО | rr_o_check | ссылка | index_organization_redirect_relationships_on_child_id,index_organization_redirect_relationships_on_stop_organization | index_organization_redirect_relationships_on_child_id | 5 | knolcano_development.rr_p_check.organization_id
    | 1 | Использование где | +----+--------------+------------------------------ -----+--------+----------------------------------- -------------------------------------------------- ------------------+---------------- ---------------------------------------+---------+ -------------------------------------------------- ----------------------+------+------ -------------+ 9 рядов в наборе (0. 00 сек) 27.10.2011

  • 2

    Однако в большинстве случаев, когда я вижу подобные вещи, это связано с плохими индексами.

    Фактический запрос и вывод EXPLAIN могут быть полезными битами информации.

    26.10.2011
    Новые материалы

    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..

    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..

    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..

    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..

    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..

    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..

    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..