EK
ну у тебя там поле company_id даже не содержит fk
Size: a a a
2021 November 27
EK
в pgsql насколько я знаю fk не создает индекс по нему и его надо создавать отдельно
EK
в mysql fk создает индекс автоматом вроде
EK
сделай explain запроса
EK
если он там читает всю таблицу companies
EK
то может лучше создать индекс и на больших данных не помещающихся в память это даст плюсы
но будет ли такая ситуация ?
но будет ли такая ситуация ?
I
Какой запрос тестировали?
I
Не пойму что за сортировка, если выборка по id, который первичный ключ
EK
ну он хочет вывести существующие компании в начало
и прицепить к ним поля настроек
я это так понял
и прицепить к ним поля настроек
я это так понял
I
А. Да, похоже на то
EK
поэтому в таблице company_settings было бы не плохо указать fk
ну и раз она используется для нахождения записи, возможно полезно было бы uniq index добавить
ну и вообще нафига там у настроек колонка id, если можно company_id юзать как pk
ну и раз она используется для нахождения записи, возможно полезно было бы uniq index добавить
ну и вообще нафига там у настроек колонка id, если можно company_id юзать как pk
EK
если только там связь 1хН между компанией и настройками
ON
Да, верно
ON
SELECT *
FROM companies_settings
INNER JOIN companies ON companies_settings.COMPANY_ID = companies.ID
ORDER BY companies.IS_EXIST;I
Так, если по колонке нет выборки и нет сортировки, зачем индекс?
ON
Имеете в виду, что индекс по
companies.IS_EXIST нужен? Но companies.IS_EXIST — это по-хорошему tinyint (1), так как в нем будет 0 и 1. Не могу изменять тип данных. Я думал, что индекс понадобится при join.ON
Подскажете как правильно запрос построить, чтобы выбрать из
companies_settings поле id и сортировать по полю companies.IS_EXIST?I
Если ваш запрос возвращает ожидаемый результат, ничего не меняйте
ON
ожидаемый, но запрос медленный :)
I
Сколько там данных?