Продолжение - просмотр FIRST_ROWS до завершения запроса

Question

Я определил конструкции запросов, которые обычно используют мои пользователи. Имеет ли для меня смысл создавать составные индексы для поддержки этих конструкций и обеспечения возможности FIRST_ROWS?

Если я перейду с SE на IDS, я потеряю способность писать низкоуровневые функции с вызовами C-ISAM, но получу FIRST_ROWS вместе с другими полезностями, такими как: SET-READS для сканирования индекса (onconfig USE_ [KO] BATCHEDREAD ), директивы оптимизатора, параллельные запросы и т. д.

---

Информация из комментариев

Производственные таблицы ломбарда запрашиваются: customer.name char (30) с использованием подстановочных знаков (LAS SUR F * для поиска фамилии LASTNAME, FIRSTNAME) или запроса pawns.ticket_number INT. Клиент и пешки объединяются: customer.name = pawns.name, а не customer.serial = pawns.fk. Пешки с датой trx старше 1 года перемещаются в историческую таблицу (> 500 тыс. Nrows) в другой базе данных на другом жестком диске. Индекс по историческим данным по убыванию trx_date. Здесь вступают в действие специальные составные конструкции запросов.

Когда найдена залоговая транзакция клиента, строка обновляется, когда клиент делает запрос интереса или погашения. Если клиенты не сделают pymt в течение 90 дней, пользователи вручную обновят, какие пешки они потеряют. pawns.status меняется на неактивный, когда клиент выкупает пешку или лишается ее из-за отсутствия pymt. неактивные перемещаются из таблицы пешек в историческую таблицу, когда их даты trx старше 1 года, поэтому массовое обновление в этом приложении не происходит. Ломбарды запускают этот процесс каждое утро перед открытием бизнеса.

{ISQL 2.10.06E (SE-DOS16M protected mode) pawns table optimization - 
 once-daily, before start of business, procedure}

 unload to "U:\UNL\ACTIVES.UNL"
    select * from pawns where pawns.status = "A"
  order by pawns.cust_name, pawns.trx_date;

 unload to "U:\UNL\INACTIVE.UNL"
    select * from pawns
     where pawns.status <> "A"
       and pawns.trx_date >= (today - 365)
  order by pawns.cust_name, pawns.trx_date desc;

 unload to "U:\UNL\HISTORIC.UNL"
    select * from pawns
     where pawns.status <> "A"
       and pawns.trx_date < (today - 365)
  order by pawns.trx_date desc;

 drop table pawns;

 create table pawns
 (
     trx_num serial,
     cust_name char(30),
     status char(1),
     trx_date date,
 . . . ) in "S:\PAWNSHOP.DBS\PAWNS";

 load from "U:\UNL\ACTIVES.UNL" insert into pawns;         {500:600 nrows avg.}
 load from "U:\UNL\INACTIVE.UNL" insert into pawns;        {6500:7000 nrows avg.}
 load from "U:\UNL\HISTORIC.UNL" insert into dss:historic; {>500K nrows}

 create cluster index pa_cust_idx on pawns (cust_name);

 {this groups each customers pawns together, actives in
  oldest trx_date order first, then inactive pawns within the last year in most 
  recent trx_date order. inactives older than 1 year are loaded into historic 
  table in a separate database, on a separate hard disk. historic table 
  optimization is done on a weekly basis for DSS queries.}

 create unique index pa_trx_num_idx on pawns (trx_num);
 create index pa_trx_date_idx on pawns (trx_date);
 create index pa_status_idx on pawns (status);

 {grant statements...}

 update statistics;

Answer 1

Нет простого ответа «да / нет» - это уравновешивание, как и в случае многих проблем с производительностью.

Есть две основные затраты, связанные с индексами, которые должны быть сбалансированы с выгодами.

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

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

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

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

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

Существует довольно хорошая книга на тему разработки индексов: Разработка индексов реляционных баз данных и оптимизаторы Лахденмяки и Лича (это также довольно дорого).

---

В последнем комментарии Фрэнк говорит:

[L] жду пару вещей. Как уже было сказано, самое простое, что нужно сделать - это позволить Informix начать возвращать строки, как только они у них появятся. (Oracle делает это по умолчанию.) Общая картина того, о чем просит Фрэнк, похожа на ту, что есть у Google. Хорошо, это действительно восходит к Alta Vista и к 90-м годам, когда мы говорили о поисковых индексах в сети. Идея состоит в том, что вы можете сделать быстрый поиск, подобрать первые n вещей, сообщив о «количестве» строк, возвращаемых в поиске. (Как будто число, указанное Google, является точным.)

Этот дополнительный комментарий Фрэнка имеет больше смысла в контексте вопроса, для которого это продолжение.

Очевидно, что если оператор SQL не заставляет Informix выполнять сортировку, он делает результаты доступными, как только они их получают; это всегда было. Подсказка по оптимизации FIRST_ROWS указывает IDS, что если у него есть выбор из двух планов запросов, и один из них позволит ему производить первые строки быстрее, чем другой, то он должен предпочесть тот, который производит первые строки быстро, даже если он в целом дороже, чем альтернатива. Даже в отсутствие подсказки IDS все еще пытается сделать данные доступными как можно быстрее - она ​​также пытается сделать это максимально эффективно.

Когда запрос подготовлен, вы получаете оценку того, сколько строк может быть возвращено - вы можете использовать это в качестве индикатора (несколько, довольно много, очень много). Кроме того, вы можете быстро и независимо определить количество строк в основной таблице, которую вы ищете. Учитывая эти метаданные, вы, безусловно, можете использовать технику с курсором прокрутки, чтобы предоставить вам резервное хранилище в базе данных, которая содержит значения первичных ключей интересующих вас строк. В любой момент вы можете загрузить массив с отображаемыми данными для набора интересных строк для отображения пользователю. По запросу пользователя вы можете организовать отображение другой страницы, полной информации. В какой-то момент процесса вы обнаружите, что достигли конца данных в курсоре прокрутки. Ясно, что если вы делаете FETCH LAST, вы заставляете это случаться. Если вы просто сделаете еще несколько FETCH NEXT, то в итоге вы получите условие NOTFOUND.

Все это стало возможным с Informix (IDS и его предыдущими воплощениями, OnLine, Turbo, SE и I4GL) с конца 80-х годов. Оптимизация FIRST_ROWS более поздняя; это все еще всего лишь подсказка оптимизатору, и, как правило, мало что меняет в том, что делает оптимизатор.