|
|
|
Порядок следования полей в индексе
|
|||
|---|---|---|---|
|
#18+
Имеется таблица mess_log ( mess_id primary key, object_id, dmessage, mess_type ) Требуется показывать сообщения по объекту отсортированные по времени select * from mess_log where object_id=:obj_id order by object_id desc, dmessage desc; И требуется для определенных видов сообщений не добавлять в базу а обновлять. То есть select max(mess_id), count(*) from mess_log where object_id=:obj_id, mess_type=:mess_type into m_id,cnt; if (cnt>0) then update .. else insert .. Вопрос 1 Какой индекс лучше create descending index ix on mess_log (obj_id, dmessage, mess_type); create descending index ix on mess_log (obj_id, mess_type, dmessage); Будет ли при втором способе сортировка или пойдем по индексу. Вопрос 2 При поиске как указать что бы count перебирал не все записи а останавливался на первой попавшейся. Вопрос 3 Как использовать rdb$db_key то есть уже найдена запись и обновлять ее надо бы не по первичному ключу, а по найденому значению rdb$db_key (примерчик бы) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2003, 15:02 |
|
||
|
Порядок следования полей в индексе
|
|||
|---|---|---|---|
|
#18+
Какой лучше индекс использовать можно узнать самому используя статистику запроса. Есть IbExpert. Там доступна вся статистика. Что касается второго индекса, то можно использовать только поле mess_type : Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2003, 15:30 |
|
||
|
Порядок следования полей в индексе
|
|||
|---|---|---|---|
|
#18+
rdb$db_key Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2003, 15:35 |
|
||
|
Порядок следования полей в индексе
|
|||
|---|---|---|---|
|
#18+
А какого типа должен быть db_key Попытки сделать его INTEGER приводят к неудаче ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2003, 09:24 |
|
||
|
Порядок следования полей в индексе
|
|||
|---|---|---|---|
|
#18+
Что такое rdb$db_key? A: Это "номер записи". Для таблиц он имеет длину 8 байт (для view - 8 байт умножить на количество таблиц в запросе, если запрос содержит явный или неявный join), которые представлены в виде строки, содержащей двоичные значения. Поэтому в ряде инструментов запрос select rdb$db_key, t.* from table t будет возвращать "мусор" в первом столбце. rdb$db_key можно использовать в качестве уникального идентификатора записи, так же как и ее поле первичного ключа. Однако rdb$db_key по ходу работы может меняться. Физически он представляет собой номер таблицы, номер страницы и смещение на запись (причем не на конкретную версию, а вообще на пакет версий этой записи, если они есть). По использованию rdb$db_key можно почитать следующие документы: Удаление или поиск дубликатов записей в таблице http://www.ibase.ru/devinfo/deldupes.htm Update данными из других таблиц http://www.ibase.ru/devinfo/updsame.htm немного о db_key (eng) http://www.ibase.ru/mail/dbkey1.txt и http://www.ibase.ru/mail/dbkey2.txt "Practical use of rdb$db_key" на английском: http://www.cvalde.com/document/practical_use_of_the_rdb.htm The mistery of rdb$db_key, на английском, в 4-х частях http://www.cvalde.com/document/mysteriousDbKey.htm ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2003, 09:36 |
|
||
|
|
start [/forum/topic.php?fid=40&msg=32183322&tid=1580361]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
157ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
| others: | 239ms |
| total: | 490ms |
| 0 / 0 |
