Запрос работает слишком медленно

• Использовать индекс.
• Если не помогло, использовать специализированный инструмент для такой задачи вместо мускуля. Хоть сфинкс, хоть редис (зависит от запроса).

Использовать индекс.

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

Во первых, про индексы уже написали,во-вторых, используюй подзапросы : и колличество обрщений к бд уменьшится в разы, и оптимизация на уровне СУБД сделает свое дело, ну и в третьих — welcome to PostgreSQL!

Покажи запрос.

Во первых, про индексы уже написали

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

используюй подзапросы : и колличество обрщений к бд уменьшится в разы, и оптимизация на уровне СУБД сделает свое дело

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

Не разрешают :(

единственный способ связать две таблицы - как раз через эти строковые параметры.

Так нужно айдишники добавить и по ним связь делать

Этот твой кладр тоже на mysql, или что-то другое? Гетерогенный запрос сделать сможешь?

Этот твой кладр тоже на mysql, или что-то другое? Гетерогенный запрос сделать сможешь?

На сколько я понял, мой запрос и так гетерогенный. У меня есть «основная» БД и БД «КЛАДР». Запрос использует таблицы и из первой, и из второй.

Так нужно айдишники добавить и по ним связь делать

В смысле, в уже существующие таблицы? Если да, то это не возможно, надо с разработчиками приложения связываться будет.

Уволиться уже предлагали? Нормализацию таблиц и добавление целочисленных id уже предлагали? Индексы уже предлагали? Партицирование?

Тему почитай, умник бл%ть. Изменить структуру БД нельзя, т.к. это повлечет за собой правки в исходном коде программы которая их юзает, а этого исходного кода у нас НЕТ. Простые меры по оптимизации запроса уже были предприняты. Про индексы тоже все написано.

Добавление столбцов по идее не должно мешать чужому коду, если только они не делают SELECT a.*, b.*

MySQL умеет индексы по строкам типа VARCHAR.

Можно сделать индекс по первым 2-3 символам в обоих таблицах, что ускорит выборку.

мускуль тут не причём и PostgreSQL в настройке сложнее, а уж в оптимизации тем более.

Тогда можно отдельную таблицу создать для связи - она не помешает основному софту.

Добавление столбцов по идее не должно мешать чужому коду, если только они не делают SELECT a.*, b.*

По идее, да, не должно. Но кто то же должен заполнять id в этом столбце? И этим занимается как раз программа. В базу руками вообще ни чего не пишется.

MySQL умеет индексы по строкам типа VARCHAR.

Спасибо, сейчас погуглю.

Тогда можно отдельную таблицу создать для связи - она не помешает основному софту.

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

тебе надо по любому с разрабами связываться, более того, тебе надо всех причастных к этому собрать и вместе смотреть проблему, у меня тоже регистрация одно время барахлила, не могли понять почему не идёт из базы данных ответа, оказалось битрикс не возвращал, и баг давно был известен разрабам. но из-за того, что мало кто делает вход и подтверждение регистрации через ЭЦП то они и не фиксили. В общем надо было сравнить сертификат который хранится в базе, и тот, что пользователь приложил сейчас, при входе уже, и вот битрикс ответ тот этот сертификат или нет не возвращал.

Но кто то же должен заполнять id в этом столбце?

Триггер, не?

Ну так заполни один раз запросом - вытянув все данные. Или у вас там новые данные постоянно добавляются?

Если добавляются - то можно триггер повесить/программно заполнять/выполнять старый запрос и т.д.

КЛАДР сам по себе тормоз, если они делают запрос в москву за ним, то ничего удивительного что у них тормозит.

Кладр правительственный или компании, только скачанный?где эта база? она ваша или нет?

ну и в третьих — welcome to PostgreSQL!

и как оно поможет? там такой проблемы автиматически не будет? :))

просто у кого то не получилось когда то 1С привязать к мускулю нормально и теперь всем постгрес суют

Ну так заполни один раз запросом - вытянув все данные. Или у вас там новые данные постоянно добавляются?

Постоянно, да.

Вообще, я хз как эти таблицы вообще можно адресовать, если не по этим строкам. В КЛАДРе id нет вообще ни где, его роль выполняет какой-то там код (varchar). И вся работа с ним осуществляется через этот код.

если они делают запрос в москву за ним, то ничего удивительного что у них тормозит.

У нас вроде локальная копия на сервере.

она ваша или нет?

Не понял вопроса.

тогда каким боком она постоянно обновляется?в упор не понимаю, она даже на их сайте обновляется не каждый день, у вас то с чего постоянно?

Уволиться уже предлагали?

Ещё в первом таком треде...

тогда каким боком она постоянно обновляется?в упор не понимаю, она даже на их сайте обновляется не каждый день, у вас то с чего постоянно?

А почему ты решил, что я про кладр говорил? Обновляются таблицы связанные с приложением.

А почему он должен уволится?Опыт работы и знания приходят с рождения? родился и уже сразу программист бд?

Нет. Но знать документацию и уметь гуглить он обязан. А по количеству тупняка, который он выдаёт, очевидно, что он пошёл работать с абсолютно нулевыми знаниями.

Тему почитай, умник бл%ть

Дык почитал, но вопросы так и остались актуальными.

Изменить структуру БД нельзя, т.к. это повлечет за собой правки в исходном коде программы которая их юзает, а этого исходного кода у нас НЕТ

Поэтому и предлагаю увольняться - с таким подходом к разработке, выбору софта, менеджменту, положительного результата ты не добьешься. Такой вот failed state, сколько не матерись, сколько не переходи на личности.

Поэтому и предлагаю увольняться - с таким подходом к разработке, выбору софта, менеджменту, положительного результата ты не добьешься. Такой вот failed state, сколько не матерись, сколько не переходи на личности.

Тут, по твоему, от меня все зависит? Я просто пишу запросы на SQL, иногда кодю на питоне. Все остально в мои обязанности не входит. Ни выбор софта, ни менеджмент, ни общение с разрабами.

Опыт работы и знания лучше получать там, где не препятствуют начальники-гидроцефалы и жопорукие (или жопоголовые) third-party разработчики.

Опыт работы и знания лучше получать там, где не препятствуют начальники-гидроцефалы и жопорукие (или жопоголовые) third-party разработчики.

Но ведь это не решит проблему кривости самого КЛАДРа, так?

При таком подходе КЛАДР тебя даже не касается. Пусть гниёт сам по себе.

Из сабжа непонятно, чем проблема его заливать в свою базу при получении и вертеть его при этом как хочешь?

Няз, кладр это справочная статика, но в треде какие-то намеки на неридонли работу с ним.

помнится что КЛАДР распространняется в формате старенького dBase (dbf), и все кто им пользуются конвертят его в свои внутренние базы (1С не исключение). Можно в принципе работать и напрямую заюзав какую-нить библиотеку - и их должны быть сотни. Также позволительно строить внешний статический индекс. Поищите в гугле - dBase linux

ps. " По скольку данных оче много, то работает это все неимоверно медленно и вешает всю базу, на долго" :-) в КЛАДРЕ данных совсем даже немного и «надолго» пишется слитно.

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

Тут, по твоему, от меня все зависит?

Чувак, если от тебя не зависит, то ты выпавшая из задачи переменная. Какой с тебя спрос если от тебя не зависит результат? Забей на задачу и расслабься.

мускуль тут не причём

Охотно верю. Но есть мнение, что postgres более оптимизирован.

PostgreSQL в настройке сложнее

Зато он гибче, и вообще мейнстрим.
По поводу Postgres vs MySQL: ничего не имею против каждой, но лично самому попадались измерения, показывающие что Postgres ведет себя шустрее и увереннее с большим объемом данных, в отличие от.

Когда основная часть времени обработки запроса, тратится на выполнения и оптимизации подзапросов, смена СУБД, как окружения для этой самой оптимизации, очень даже может помочь.

Вот ты пишешь, пишешь... Тебе же сказали - индекс сделай по варчарам. Только смотри внимательно - там надо задавать длину по которой делается индекс. Я бы поставил 2 или 3. По дефолту кажется 10 и такой тебе точно не поможет.

воу воу воу, зачем id?

КЛАДР в своей основе имеет код вида 02000001000000200...

Где зашиты обасть, город, улица и пр.

КЛАДР в своей основе имеет код вида 02000001000000200...
Где зашиты обасть, город, улица и пр.

Так я же пол треда пытаюсь донести, что сравниваю я как раз по коду. Но работает это сравнение очень медленно.

Ну если кода КЛАДРа не хранятся отдельно по каждой сущности(область, город, район, улица и прочее), то дело швах. Индексирование полного кода КЛАДРа особо не поможет.

А так партиционирование по, например, «кладру города» дало бы существенный выигрыш.

А так партиционирование по, например, «кладру города» дало бы существенный выигрыш.

А, пардон, какое партиционирование в мускуле. Тогда банальный индекс.