sampath1750 Ответов: 1

Проблема производительности выполнения запросов MYSQL

ПРИВЕТ,

Я с помощью C#, сервер БД MySQL.

У меня есть 3 таблицы в БД, 1-я таблица имеет 1,5 лакх записей, 2-я таблица имеет 1,75 лакх записей и 3-я таблица имеет 21 лакх записей. мне нужен вывод с использованием выше 3 таблиц, поэтому я присоединился к выше 3 таблицам с помощью внутреннего соединения и получил вывод с записями 1,5 лакха, но для этого требуется 8 часов времени.

Я использовал первичные ключи при соединении таблиц, может ли кто-нибудь предложить мне увеличить производительность.

Спасибо!

Что я уже пробовал:

выберите Col1, col2, ... coln из таблицы 1
Соедините таблицу 2 с таблицей 1.ИД = таблица2.Идентификатор
Присоединяйтесь таблица3 таблицы table1.ИД = таблица3.Идентификатор

Richard MacCutchan

Что вы планируете делать с 1,5 лакхами (150 000) записей? Как вы думаете, какой-нибудь пользователь будет заинтересован в том, чтобы прочитать их все? Используйте правильные критерии выбора и пейджинг, чтобы сделать ваше приложение пригодным для использования.

sampath1750

Нам нужно отобразить результирующий набор, поэтому мы сохранили этот результирующий набор в другой таблице и отобразили результирующий набор.

Richard MacCutchan

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

0x01AA

Где это было упомянуто, это должно быть показано? Во всяком случае, такой случай (выберите 150k записей) может легко произойти во время некоторого интеллектуального анализа данных...

David_Wimbley

ОП ясно говорит:" нам нужно отобразить результирующий набор " в комментарии, на который ответил Ричард.

Richard MacCutchan

Читать вопрос.

0x01AA

Я не думаю, что 150 тысяч записей будут проблемой (до тех пор, пока вы не представите их пользователю). То, что я узнал с MSSQL, ограничение внешнего ключа не определяет индекс автоматически (например, interbase делает это автоматически). Поэтому сначала проверьте, индексируются ли внешние ограничения ;)

1 Ответов

Рейтинг:
1

David_Wimbley

Я согласен с Ричардом, ваша первая проблема с этим-ваш дизайн. Нет никакого требования, чтобы вы могли иметь то, что вам абсолютно необходимо, чтобы показать все 150 000 записей сразу.

Но давайте предположим, что вы определили, что это 150 тысяч записей или бюст.

Мой первый комментарий состоял бы в том, чтобы изучить разбиение ваших данных на страницы, я думаю, что mysql имеет понятие предела (я ржавый на своем mysql), но позволил бы вам сделать что-то вроде SELECT * FROM <Table> LIMIT 5,10 что позволило бы вам получить 5 записей, начиная с 5-й записи. Я скажу вам, что ни один из ваших пользователей не оценит необходимость просматривать 150 тысяч записей, чтобы попытаться найти специфику того, что они хотят. Вам лучше отфильтровать эти данные в соответствующий результирующий набор, чем пытаться показать их все сразу, ваши пользователи возненавидят вас, если им придется вручную фильтровать эти данные самостоятельно.

Затем вам нужно посмотреть на оборудование ваших серверов. 150 тысяч записей за 8 часов-это смешно. Я могу запустить аналогичный запрос в sql server (предоставленный в другой платформе БД) и получить 150 тысяч записей с объединением трех таблиц за несколько секунд. 8 часов для 150k записей, вы запускаете свою БД на одном ядре с 500 МБ оперативной памяти? Так что изучите свои аппаратные проблемы

Посмотрите на то, что вы спрашиваете. 8 часов для такого количества записей, вы должны вытащить 10 000 столбцов или что-то в этом роде...вы делаете какую-то сумасшедшую агрегацию, которую, возможно, можно разгрузить, сохранив данные в требуемом агрегированном виде для начала? Например, если вы всегда добавляете 4 столбца для создания итога, почему бы просто не добавить пятый столбец под названием "Итого" и не хранить этот итог там, чтобы вам не приходилось делать математику каждый раз, когда вы его запрашиваете.

Чтобы согласиться с последним комментарием, вам нужно также посмотреть на ваш запрос, чтобы увидеть, что в вашем запросе может быть настроено. Вы делаете подзапросы без необходимости? Не могли бы вы использовать временные таблицы для некоторых ваших соединений? Может ли какой-то из ваших запросов, которые вы делаете, быть ненужным, если вы добавите больше столбцов в свою схему? Я думаю, что в mysql есть ключевое слово called EXPLAIN это вы можете использовать для того, чтобы ваш запрос профилировался по мере его выполнения, чтобы вы могли анализировать происходящее.

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

0x01AA

Почему 150 тысяч записей должны быть проблемой? Где ОП упомянул, что это для GUI? См. мои комментарии к этому вопросу. Никакого голосования с моей стороны.

David_Wimbley

ОП запрашивает 150 тысяч записей и говорит, что это занимает 8 часов и упоминает только "выход".

Как вы думаете, где он находится или не находится для Гуи? Он должен куда-то идти, будь то в файл или в графический интерфейс, 8 часов, чтобы получить 150 тысяч записей из БД, - это безумие.

Не лоббируя голосование, а просто исправляя неправильное представление о том, что мой ответ касается только производительности графического интерфейса. Мои указания на его вопрос касаются проблем с аппаратным обеспечением, производительностью запросов (объясните, запрашивая схему/запрос) и вариантами рендеринга данных в более управляемом формате, будь то csv/плоский файл/графический интерфейс.

Richard MacCutchan

А Таблица 3 - это 2 100 000 записей, которые должны быть присоединены к двум другим, так что я подозреваю, что это может повлиять на время.