Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Запрос!
|
|||
|---|---|---|---|
|
#18+
Добрый день! Есть следующий запрос: select tab1.*, tab2.* from tab1 inner join tab2 on tab1.col1 = tab2.col2 where ((tab2.date>='2008-04-08 10:59:07.193000' ) and (tab2.DATE<='2009-04-08 10:59:07.193000' )) tab1~1M tab2~1M tab2.col2 - PK tab2.date - index tab1.col1 - нет индекса и колонка пустая, то бишь все NULL. Запрос выполняется довольно долго ~30 секунд выдает естественно 0 значений. Вопрос, если смысл добавлять индекс на tab1.col1? Не вызовет ли это сильного ухудшения перфоманса при insert/update/delete? Можно ли как-то переписать запрос, чтобы он выполнялся быстрее без добавления индекса на tab1.col1? Заранее спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2010, 16:52 |
|
||
|
Запрос!
|
|||
|---|---|---|---|
|
#18+
Может можно сделать какую-то проверку перед джойном: если в колонки все is NULL, тогда джойн выполнять не надо, а просто вывести 0 rows? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2010, 17:03 |
|
||
|
Запрос!
|
|||
|---|---|---|---|
|
#18+
а самому попробовать с индексом влом? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2010, 17:03 |
|
||
|
Запрос!
|
|||
|---|---|---|---|
|
#18+
ananas2 inner join tab2 on tab1.col1 = tab2.col2 where ... tab1.col1 - нет индекса и колонка пустая, то бишь все NULL. При таких условиях выражение tab1.col1 = tab2.col2 будет всегда ложно (NULL не равно ничему, в том числи и другому NULL), следовательно, запрос всегда будет возвращать пустой набор. Таким образом, этот запрос можно просто не выполнять для достижения искомого результата. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2010, 17:03 |
|
||
|
Запрос!
|
|||
|---|---|---|---|
|
#18+
mustaccioananas2 inner join tab2 on tab1.col1 = tab2.col2 where ... tab1.col1 - нет индекса и колонка пустая, то бишь все NULL. При таких условиях выражение tab1.col1 = tab2.col2 будет всегда ложно (NULL не равно ничему, в том числи и другому NULL), следовательно, запрос всегда будет возвращать пустой набор. Таким образом, этот запрос можно просто не выполнять для достижения искомого результата. Да, это так, но суть в том что данные в tab1.col1 когда-нибудь появятся, это сейчас их нет. А запрос уже используется вовсю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2010, 17:18 |
|
||
|
Запрос!
|
|||
|---|---|---|---|
|
#18+
gardenmanа самому попробовать с индексом влом? К сожалению нет доступа к этой базе. При создании виртуального индекса, access план ничего ничего хорошего не говорит. Кстати, если подскажете как потом проверить улучшение, ухудшение скорости операций insert/update/delete буду благодарен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2010, 17:28 |
|
||
|
Запрос!
|
|||
|---|---|---|---|
|
#18+
Mark Barinsteinananas2, Добрый день. db2advis умеете пользоваться? Умею, нет прав к этой базе. Есть ли смысл пробовать на тестовой базе, где намного меньшие объемы данных? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2010, 17:30 |
|
||
|
Запрос!
|
|||
|---|---|---|---|
|
#18+
ananas2Умею, нет прав к этой базе. Есть ли смысл пробовать на тестовой базе, где намного меньшие объемы данных?Ну, если распределение данных примерно похоже, то да, имеет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2010, 17:57 |
|
||
|
Запрос!
|
|||
|---|---|---|---|
|
#18+
Mark Barinsteinananas2Умею, нет прав к этой базе. Есть ли смысл пробовать на тестовой базе, где намного меньшие объемы данных?Ну, если распределение данных примерно похоже, то да, имеет. Попробовал, он предлагает составной индекс сделать (tab2.col2 + tab2.date) вместо 2х текущих, чтобы сортировку избежать. Но это меня не особо интересует. так как основной стопор явно на джойне. По поводу tab1.col1 db2advis не говорит ничего. Значит, толку от создания индекса tab1.col1 не будет никакого? Но ведь если подумать - он проиндексирует столбец с нулями и при джойне не должен потом проверять каждый ноль соответственно скорость выполнения должна значительно увеличится. Или я неправильно рассуждаю? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2010, 18:12 |
|
||
|
Запрос!
|
|||
|---|---|---|---|
|
#18+
ananas2Mark Barinsteinпропущено... Ну, если распределение данных примерно похоже, то да, имеет. Попробовал, он предлагает составной индекс сделать (tab2.col2 + tab2.date) вместо 2х текущих, чтобы сортировку избежать. Но это меня не особо интересует. так как основной стопор явно на джойне. По поводу tab1.col1 db2advis не говорит ничего. Значит, толку от создания индекса tab1.col1 не будет никакого? Но ведь если подумать - он проиндексирует столбец с нулями и при джойне не должен потом проверять каждый ноль соответственно скорость выполнения должна значительно увеличится. Или я неправильно рассуждаю?Попробуйте создать этот индекс, может и поможет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2010, 10:14 |
|
||
|
Запрос!
|
|||
|---|---|---|---|
|
#18+
ananas2, Код: plaintext 1. Далеко не факт что сейчас поможет, но оптимальнее возвращать те поля которые действительно необходимы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2010, 11:34 |
|
||
|
Запрос!
|
|||
|---|---|---|---|
|
#18+
Mark Barinstein, Есть запрос который получает номер человека и платежи по карте. Нужно получить номера людей и их номера карт по самому последнему платежу. Тут возможно так что человек в течении года платил по одной карте, а потом стал платить по-другой. У меня получилось что-то вроде этого: ... 12345 Иванов 111-222-333 12345 Иванов 444-555-666 ... А надо так ... 12345 Иванов 444-555-666 ... потому что последний платеж был по этой карте!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2010, 06:08 |
|
||
|
Запрос!
|
|||
|---|---|---|---|
|
#18+
Извиняюсь за не полноту предоставленой информации!!! Есть 2 таблицы которые соединяются по номеру человека: 1- Человек 2- Платеж ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2010, 09:25 |
|
||
|
Запрос!
|
|||
|---|---|---|---|
|
#18+
как-то так... Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2010, 10:03 |
|
||
|
Запрос!
|
|||
|---|---|---|---|
|
#18+
НиколахаMark Barinstein, Есть запрос который получает номер человека и платежи по карте. Нужно получить номера людей и их номера карт по самому последнему платежу. Тут возможно так что человек в течении года платил по одной карте, а потом стал платить по-другой. У меня получилось что-то вроде этого: ... 12345 Иванов 111-222-333 12345 Иванов 444-555-666 ... А надо так ... 12345 Иванов 444-555-666 ... потому что последний платеж был по этой карте!!! Зависит от того, как именно вы определяете "последний" платёж - по самой последней его дате, внутреннему номеру или ещё как... Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2010, 10:34 |
|
||
|
Запрос!
|
|||
|---|---|---|---|
|
#18+
Mark Barinstein, да правильное решение, но видимо из-за того что я не правильно объяснил!!! Платежей то может быть много, а из запроса видно, что возьмется одна запись Например: ... 12345 Иванов 111-222-333 12345 Иванов 444-555-666 ... 54321 Петров 123-123-123 54321 петров 321-321-321 ... А надо так: ... 12345 Иванов 444-555-666 ... 54321 петров 321-321-321 ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2010, 11:27 |
|
||
|
Запрос!
|
|||
|---|---|---|---|
|
#18+
Николаха, Я вас не понимаю. Вы можете просто взять и выполнить мой пример как есть, без изменений, и по результатам показать, что именно вам не нравится? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2010, 11:48 |
|
||
|
|

start [/forum/topic.php?fid=43&msg=36934516&tid=1602447]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
34ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
| others: | 273ms |
| total: | 388ms |

| 0 / 0 |
