| Начало » Использование СУБД » Firebird, HQbird, InterBase » Сортировка в большом количестве записей Переход к форуму:
	| 
		
			| Сортировка в большом количестве записей [сообщение #5307] | Tue, 06 August 2024 12:12  |  
			| 
				
				
					|  crazypiggy Сообщений: 2
 Зарегистрирован: August 2024
 | Junior Member |  |  |  
	| Добрый день. У меня есть три таблицы OBJECTS (ID ,  PARENT_ID , FULL_NAME, SHORT_NAME, LEVEL_ID,  FIAS_GUID) в которой хранятся адреса до уровня улицы, переулок и т.д. HOUSES (ID, OBJECTS_ID, NUM, KORP) таблица домов привязанных к OBJECTS и абонентов ABONENTS (ID, HOUSES_ID, APARTMENT, ROOM, MANAGER_ID)
 В таблице ABonents количество записей около 1.5 млн. Мне надо сделать получение записи по порядку. Но если я делаю order by FULL_NAME, NUM, KORP, APARTMENT это занимает достаточно большое время.
 Все записи мне тоже не нужны сразу, надо по одной. Подскажите как правильно реализовать проход по порядку по этому набору данных с минимальным временем. Спасибо.
 
 Это я так пытаюсь получить весь набор данных а потом уже по нему проходить. Но так наверное не очень хорошо и скорость невысокая.with recursive OBJ (ID, FULL_NAME, PARENT_ID, LEVEL_ID) as
 (select id, FULL_NAME, PARENT_ID, LEVEL_ID from objects where parent_id is null
 union all
 select obj_l.id, obj_l.FULL_NAME, obj_l.PARENT_ID, obj_l.LEVEL_ID from objects obj_l
       join obj on obj_l.parent_ID=obj.id)
select  * from obj
 join houses on houses.objects_id=obj.id
 join abonents on abonents.houses_id=houses.id 
order by LEVEL_ID, FULL_NAME, NUM, KORP, APARTMENT, ROOM
 
 [Обновления: Tue, 06 August 2024 12:34] Известить модератора |  
	|  |  |  
	|  |  
	|  |  
	|  |  
	|  |  
	|  |  
	|  |  
	| 
		
			| Re: Сортировка в большом количестве записей [сообщение #5314 является ответом на сообщение #5313] | Wed, 07 August 2024 05:29   |  
			| 
				
				
					|  fraks Сообщений: 152
 Зарегистрирован: June 2022
 Географическое положение: Новосибирск
 | Senior Member |  |  |  
	| Что бы получить хороший ответ нужно подготовить вопрос в таком виде что бы он не вызывал потребности задавать дополнительные вопросы т.к. на это уходит куча времени. 
 Начать с версии сервера.
 Потом DDL.
 
 
 Тут, естественно, нужно указать и типы данных, и первичные и прочие ключи, и индексы.-- адреса до уровня улицы, переулок и т.д.
CREATE TABLE OBJECTS (
  ID ,  
  PARENT_ID , 
  FULL_NAME, 
  SHORT_NAME, 
  LEVEL_ID,  
  FIAS_GUID
);
-- дома, привязанные к OBJECTS
CREATE TABLE HOUSES (
  ID, 
  OBJECTS_ID, 
  NUM, 
  KORP
);
-- абоненты 
CREATE TABLE ABONENTS (
  ID, 
  HOUSES_ID, 
  APARTMENT, 
  ROOM, 
  MANAGER_ID
);
 Цитата:
 В таблице ABonents количество записей около 1.5 млн.Мне надо сделать получение записи по порядку.
 
 Хорошо бы указать кол-во записей в других таблицах, а так же количество левелов.
 
 Цитата:
 Но если я делаю order by FULL_NAME, NUM, KORP, APARTMENT это занимает достаточно большое время.
 А если делать сортировку только по obj.LEVEL_ID то как со временем? Устраивает?
 Если хорошо, то вероятно хватается неэффективный в данном случае индекс по OBJECTS.FULL_NAME есть он или нет, ты не сказал.
 
 Можно попробовать исключить лишние индексы, задав сортировку внутри левела натуралом, возможно так будет выстрее выдаваться.
 
 
 with recursive OBJ (ID, FULL_NAME, PARENT_ID, LEVEL_ID) as (
  select id, FULL_NAME, PARENT_ID, LEVEL_ID 
  from objects
  where parent_id is null
  
  union all
  
  select obj_l.id, obj_l.FULL_NAME, obj_l.PARENT_ID, obj_l.LEVEL_ID
  from objects obj_l
    join obj on (obj_l.parent_ID = obj.id)
)
select *
from obj
  join houses   on (houses.objects_id  = obj.id    )
  join abonents on (abonents.houses_id = houses.id )
order by
  obj.LEVEL_ID,
  obj.FULL_NAME      + '', -- отключаем использование индекса
  houses.NUM         + '', -- отключаем использование индекса
  houses.KORP        + '', -- отключаем использование индекса
  abonents.APARTMENT + '', -- отключаем использование индекса
  abonents.ROOM      + ''  -- отключаем использование индекса
 |  
	|  |  |  
	|  |  
	|  |  
	|  |  
	|  |  
	|  | 
 
 
 Текущее время: Fri Oct 31 16:59:51 GMT+3 2025 
 Общее время, затраченное на создание страницы: 0.00877 секунд |