|
|
|
Как правильно построить индексы для соединения двух таблиц по двум полям?
|
|||
|---|---|---|---|
|
#18+
Такая задача: Есть две таблички, в которые я для примера переливаю записи: Код: plaintext 1. 2. 3. 4. 5. 6. 7. Затем создаю по 2 индекса в каждой табличке: Код: plaintext 1. 2. 3. 4. 5. 6. 7. При выполнении выборки, оптимизатор игнорирует индекс: Код: plaintext 1. 2. 3. Пропобовал создавать составной индекс, не помогает :( Код: plaintext 1. 2. Подскажите пожалуйста, что не так? best regards, win-kim ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2005, 08:08 |
|
||
|
Как правильно построить индексы для соединения двух таблиц по двум полям?
|
|||
|---|---|---|---|
|
#18+
win-kim ... Подскажите пожалуйста, что не так? Информикс 7-мой? Тогда не так это varchar(50). Пробуй с char(50). Если не 7-мой тогда таблички очень маленькие и секскан дешевле, попробуй не собирать статистику. И покажи план для вариантов со статистикой и без. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2005, 08:40 |
|
||
|
Как правильно построить индексы для соединения двух таблиц по двум полям?
|
|||
|---|---|---|---|
|
#18+
ver Informix 9.4 количество записей в таблицах: 20319 План выполнения запроса без обновления статистики в таблицах(теперь показывает, что использует индексы, и трудозатраты минимальные, но реально также долго выполняется (60 секунд)): Код: 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. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Еще одно примечание, у меня в поле f1 повторяются значения, а в поле f2 значения уникальны в пределах f1. Т.е. как бы составной ключ f1, f2, которого нет. best regards, win-kim ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2005, 09:11 |
|
||
|
Как правильно построить индексы для соединения двух таблиц по двум полям?
|
|||
|---|---|---|---|
|
#18+
win-kimver Informix 9.4 количество записей в таблицах: 20319 А count(*) сколько показывает-то? для 20319 строк HASH JOIN (у вас optcomind ведь 2) это правильно и индексы не нужны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2005, 09:22 |
|
||
|
Как правильно построить индексы для соединения двух таблиц по двум полям?
|
|||
|---|---|---|---|
|
#18+
Кстати AVOID_INDEX это как раз директива НЕ использовать индекс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2005, 09:25 |
|
||
|
Как правильно построить индексы для соединения двух таблиц по двум полям?
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. Код: plaintext 1. Журавлев Денис для 20319 строк HASH JOIN (у вас optcomind ведь 2) это правильно и индексы не нужны. Я думаю, что запрос на соединении двух таблиц по 20 тыс строк, который выполняется пол минуты это неправильно. По одному полю соединение таблиц в 1 млн строк идет быстрее. Все таки нужно как то сделать быстрее. Журавлев Денис Кстати AVOID_INDEX это как раз директива НЕ использовать индекс. Я имел ввиду FULL_INDEX best regards, win-kim ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2005, 09:48 |
|
||
|
Как правильно построить индексы для соединения двух таблиц по двум полям?
|
|||
|---|---|---|---|
|
#18+
win-kimЯ думаю, что запрос на соединении двух таблиц по 20 тыс строк, который выполняется пол минуты это неправильно. Попробуй тип поля поменять на char(50). Для индекса фиксированная длина поля - важно, вроде... Сама по себе задача построения индекса по строковому полю с длиной 50 а потом соединение по этому индексу - очень тяжелая задача для сервера... Оправдываться (т.е. соединение будет происходить быстрее чем по скану) использование индекса начнет только на очень больших размерах таблиц. А до тех пор впустую будут тратиться системные ресурсы на поддержание актуальности индекса (а это очень много, учитывая по каким полям он построен). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2005, 10:11 |
|
||
|
Как правильно построить индексы для соединения двух таблиц по двум полям?
|
|||
|---|---|---|---|
|
#18+
win-kim 20319 Тогда второй план точно правильный. Индексы не нужны. Статистика нужна. NONPDQMEMORY нужна. win-kim По одному полю соединение таблиц в 1 млн строк идет быстрее. Все таки нужно как то сделать быстрее. А в результате тоже мульон и тоже считаешь count*? План покажи. Не верится что-то. win-kim Я имел ввиду FULL_INDEX Такого хинта вообще нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2005, 10:13 |
|
||
|
Как правильно построить индексы для соединения двух таблиц по двум полям?
|
|||
|---|---|---|---|
|
#18+
Valentyn Pidburtnyi Попробуй тип поля поменять на char(50). Для индекса фиксированная длина поля - важно, вроде... Нет, ему пофигу. В индексе будет фиксированная что для char что для varchar. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2005, 10:19 |
|
||
|
Как правильно построить индексы для соединения двух таблиц по двум полям?
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис win-kim 20319 Тогда второй план точно правильный. Индексы не нужны. Статистика нужна. NONPDQMEMORY нужна. win-kim По одному полю соединение таблиц в 1 млн строк идет быстрее. Все таки нужно как то сделать быстрее. А в результате тоже мульон и тоже считаешь count*? План покажи. Не верится что-то. win-kim Я имел ввиду FULL_INDEX Такого хинта вообще нет. извиняюсь, снова опечатался AVOID_FULL FULL А на счет млн строк, тама идет соединение таблички в 1 млн строк с табличкой в 50 тыс строк идет около 20 секунд (вставка в другую). Но не в этом суть, меня не устраивает скорость по соединению по двум полям. заменил varchar(50) на char(50), та же фигня. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Журавлев Денис NONPDQMEMORY нужна. а что это? best regards, win-kim ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2005, 11:05 |
|
||
|
Как правильно построить индексы для соединения двух таблиц по двум полям?
|
|||
|---|---|---|---|
|
#18+
win-kim Журавлев Денис NONPDQMEMORY нужна. а что это? При хеш джойне будет хештаблица размером 60 байт(строка)*20319 ~ 1,6 мегабайта наверняка в память сессии она не влезает и будет лежать в темпе. В 9.40.xC4 появился параметр DS_NONPDQ_QUERY_MEM который позволяет увеличить кол-во памяти для сессии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2005, 11:21 |
|
||
|
Как правильно построить индексы для соединения двух таблиц по двум полям?
|
|||
|---|---|---|---|
|
#18+
win-kim А на счет млн строк, тама идет соединение таблички в 1 млн строк с табличкой в 50 тыс строк идет около 20 секунд (вставка в другую). Там в результате соединения получается сколько строк (сколько инсертятся)? win-kim Но не в этом суть, меня не устраивает скорость по соединению по двум полям. Кол-во полей ни на что не влияет, я постоянно вижу как таблицы соединяют по десяти полям и что? По моему оба плана абсолютно нормальные и индекс нужен либо на одной из таблиц (NL) как в первом случае, либо не нужен вообще (HJ) как во втором (но тут нужна low статистика). ЗЫЖ Естественно поможет pdq, во втором случае (HJ) ускорится сильно, в первом меньше -- распаллелится только первый шаг (секскан). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2005, 11:30 |
|
||
|
Как правильно построить индексы для соединения двух таблиц по двум полям?
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис win-kim А на счет млн строк, тама идет соединение таблички в 1 млн строк с табличкой в 50 тыс строк идет около 20 секунд (вставка в другую). Там в результате соединения получается сколько строк (сколько инсертятся)? Точно не помню, окола 100 тыс. Журавлев Денис win-kim Но не в этом суть, меня не устраивает скорость по соединению по двум полям. Кол-во полей ни на что не влияет, я постоянно вижу как таблицы соединяют по десяти полям и что? По моему оба плана абсолютно нормальные и индекс нужен либо на одной из таблиц (NL) как в первом случае, либо не нужен вообще (HJ) как во втором (но тут нужна low статистика). Блин, значит быстрее никак? Это риторический вопрос, отвечать не надо :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2005, 11:42 |
|
||
|
Как правильно построить индексы для соединения двух таблиц по двум полям?
|
|||
|---|---|---|---|
|
#18+
win-kimТакая задача: Есть две таблички, в которые я для примера переливаю записи: Код: plaintext 1. 2. 3. 4. 5. 6. 7. Затем создаю по 2 индекса в каждой табличке: Код: plaintext 1. 2. 3. 4. 5. 6. 7. При выполнении выборки, оптимизатор игнорирует индекс: Код: plaintext 1. 2. 3. Пропобовал создавать составной индекс, не помогает :( Код: plaintext 1. 2. Подскажите пожалуйста, что не так? best regards, win-kim 1. Думаю скорость обьединения возрастет если составной индекс построить наоборот create index idx_t1_f1_f2 on t1(f2, f1); create index idx_t2_f1_f2 on t2(f2, f1); Но это зависит от статистического распределения значений в поле f2. 2. Насколько я помню в каких то версиях был баг или фича при использовании индексного поиска по плям varchar. А при использовании типа char все строки при храненнии будут дополненны пробелами до полной длины(50 байт в вашем случае). В результате в случае NESTED LOOP JOIN сервер буде сравнивать пробелы, а в случае HASH JOIN уникальность результата hash функции будет непредсказуема, и реальная стоимось может на порядки отличаться от того что предполагает план запроса, здесь cможет помочь только update statistics high и то не всегда. 3.Думаю нужно подумать о искуственных ключах. В худшем случае вы потеряете 8 байт в каждой записи, зато получите прогнозированную производительнось, которая будет граздо выше текущей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2005, 11:45 |
|
||
|
Как правильно построить индексы для соединения двух таблиц по двум полям?
|
|||
|---|---|---|---|
|
#18+
Может все дело в групповом операторе COUNT или SUM или ... Попробуй в целевом списке задать имя поля .... результат соединение таблиц разместить вв времменой таблице ... далее используй COUNT для результирующей выборки ....:) GVF112 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2005, 11:53 |
|
||
|
Как правильно построить индексы для соединения двух таблиц по двум полям?
|
|||
|---|---|---|---|
|
#18+
onstat- win-kim Такая задача: Есть две таблички, в которые я для примера переливаю записи: create temp table t1(f1 varchar(50), f2 int8); create temp table t2(f1 varchar(50), f2 int8); insert into t1 select referens, rs_rownum from table; insert into t2 select referens, rs_rownum from table; Затем создаю по 2 индекса в каждой табличке: create index idx_t1_f1 on t1(f1); create index idx_t1_f2 on t1(f2); update statistics medium for table t1; create index idx_t2_f1 on t2(f1); create index idx_t2_f2 on t2(f2); update statistics medium for table t2; При выполнении выборки, оптимизатор игнорирует индекс: select count(*) from t2 A, t1 where A.f1=t1.f1 and A.f2=t1.f2; Если указывать директивы AVOID_INDEX и т.д., то оптимизатор начинает использовать индекс, но на производительность это сказывается отрицательно. Пропобовал создавать составной индекс, не помогает :( create index idx_t1_f1_f2 on t1(f1, f2); create index idx_t2_f1_f2 on t2(f1, f2); Подскажите пожалуйста, что не так? best regards, win-kim 1. Думаю скорость обьединения возрастет если составной индекс построить наоборот create index idx_t1_f1_f2 on t1(f2, f1); create index idx_t2_f1_f2 on t2(f2, f1); Но это зависит от статистического распределения значений в поле f2. Построил индекс: create index idx_t1_f2_f1 on t1(f2,f1); update statistics medium for table t1; create index idx_t2_f2_f1 on t2(f2,f1); update statistics medium for table t2; Без директивы оптимизатор индексы не использует. А с директивой стоимость запроса большая. Вобщем результат нет. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2005, 11:53 |
|
||
|
Как правильно построить индексы для соединения двух таблиц по двум полям?
|
|||
|---|---|---|---|
|
#18+
win-kim(1) Index Keys: f2 f1 (Key-Only) (Serial, fragments: ALL) (1) Index Keys: f2 f1 (Key-Only) (Serial, fragments: ALL) DYNAMIC HASH JOIN Гыгыгы (оптимайзер не обманешь). Надо было тогда его домучать use_nl. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2005, 12:18 |
|
||
|
Как правильно построить индексы для соединения двух таблиц по двум полям?
|
|||
|---|---|---|---|
|
#18+
Ключевая фраза эта onstat Но это зависит от статистического распределения значений в поле f2. win-kim Построил индекс: Код: plaintext 1. 2. 3. 4. 5. Без директивы оптимизатор индексы не использует. А с директивой стоимость запроса большая. Вобщем результат нет. Если есть возможность зделайте update statistics drop distribution; Я непомню можно ли его делать для конкретной таблицы. А потом update statistics medium .... Я сталкивался с кривой статистикой в случае если сначала делать low, а потом переходить на medium | high без удаления старой сратистики. Если не поможет, нужно менять логику приложения, Если вы даже и добьетесь удовлетворительно результата при определенном статистическом распределении, то другое распределение может дать замедление на порядки особенно с использованем HASH JOIN даже при одинаковом cost. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2005, 12:24 |
|
||
|
Как правильно построить индексы для соединения двух таблиц по двум полям?
|
|||
|---|---|---|---|
|
#18+
onstat- 1. Думаю скорость обьединения возрастет если составной индекс построить наоборотТеоритически от этого в данном случае изменится не должно ничего. onstat- 2. Насколько я помню в каких то версиях был баг или фича при использовании индексного поиска по плям varchar. В семерке. onstat- А при использовании типа char все строки при храненнии будут дополненны пробелами до полной длины(50 байт в вашем случае). В индексах оно и так (char) и сяк (varchar) пробелами будет дополнено. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2005, 12:27 |
|
||
|
Как правильно построить индексы для соединения двух таблиц по двум полям?
|
|||
|---|---|---|---|
|
#18+
onstat- Если есть возможность зделайте update statistics drop distribution; Я непомню можно ли его делать для конкретной таблицы. А потом update statistics medium .... Я сталкивался с кривой статистикой в случае если сначала делать low, а потом переходить на medium | high без удаления старой сратистики. Если не поможет, нужно менять логику приложения, Если вы даже и добьетесь удовлетворительно результата при определенном статистическом распределении, то другое распределение может дать замедление на порядки особенно с использованем HASH JOIN даже при одинаковом cost. Как вы заметили таблички временные, поэтому я думаю операция чистки статистики не имеет смысла... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2005, 12:38 |
|
||
|
Как правильно построить индексы для соединения двух таблиц по двум полям?
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис onstat- 1. Думаю скорость обьединения возрастет если составной индекс построить наоборотТеоритически от этого в данном случае изменится не должно ничего. Теоретически ничего не поменяется если строки не дополнены пробелами. Если же занчащая часть строк состоит из 10 байт, то для того, что бы перйти к проверке на совпадение 2 -го поля, нужно сравнить между собой 40 байт пробелов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2005, 12:40 |
|
||
|
Как правильно построить индексы для соединения двух таблиц по двум полям?
|
|||
|---|---|---|---|
|
#18+
Че-то у вас не то получается. Мои результаты - выполняется практически мгновенно. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. Kbytes, никаких настроек сервера не делал, все по умолчанию. В таком вот аксепте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2005, 20:09 |
|
||
|
Как правильно построить индексы для соединения двух таблиц по двум полям?
|
|||
|---|---|---|---|
|
#18+
Переделал процедуру на повторяющтиеся значения в f1 : Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. В таком вот аксепте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2005, 20:18 |
|
||
|
Как правильно построить индексы для соединения двух таблиц по двум полям?
|
|||
|---|---|---|---|
|
#18+
Да, в insert into tbl values ((i mod 10) || ' ', i); HTML сожрал 30 пробелов из скрипта. В таком вот аксепте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2005, 20:23 |
|
||
|
Как правильно построить индексы для соединения двух таблиц по двум полям?
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. В случае 2.4 я заставляю его NL (2 сек.) и это быстрее чем его HJ (16 сек.). Он выбирает HJ из-за OPTCOMPIND 2, случай 2.5 это подтверждает. В общем индексы не нужны, все равно HJ+PDQ быстрее, плюс нет потери на создание индекса 2 сек. и сбор статистики 0.5 сек. Хотя возможен вариант и без PDQ, но либо OPTCOMPIND 0, либо хинтами учитесь рулить правильно. Лучший результат 0.3 секунды. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2005, 23:39 |
|
||
|
|

start [/forum/topic.php?fid=44&fpage=54&tid=1608827]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
25ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
71ms |
get tp. blocked users: |
2ms |
| others: | 226ms |
| total: | 367ms |

| 0 / 0 |
