|
|
|
ASE 12.5 - поиск в строке, что быстрее?
|
|||
|---|---|---|---|
|
#18+
Господа, такой скорее теоретический вопрос. Есть запросы котором есть SARG по индексированному полю и есть SARG ищущий в строке. Т.е поиск второго SARG будет осуществляться перебором записей в страницах данных отобранных 1м SARG. Сам поиск в строке можно реализовать одним из 3х способов: where substring(x,1,4)='blah' or substring(x,1,4)='foob' where substring(x,1,4) in ('blah', 'foob') where x like 'blah%' or x like 'foob%' Кластеризации по полю x нет, так что с этой стороны у like нет премущества. Вопрос - будет ли какой-нибудь из 3х способов работать быстрее и почему? Заранее спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2010, 19:31 |
|
||
|
ASE 12.5 - поиск в строке, что быстрее?
|
|||
|---|---|---|---|
|
#18+
Вот ещё такой вопрос - в I/O подобные задачи измерять смысла нет, т.к. вопрос про то что быстрее like или substring. Можно ли как-нибудь измерить стоимость этих операций? Заранее большое спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2010, 20:22 |
|
||
|
ASE 12.5 - поиск в строке, что быстрее?
|
|||
|---|---|---|---|
|
#18+
Kru пишет: > Есть запросы котором есть SARG по индексированному полю и есть SARG > ищущий в строке. > > Т.е поиск второго SARG будет осуществляться перебором записей в > страницах данных отобранных 1м SARG. Запросы целиком, пожалуйста. > Сам поиск в строке можно реализовать одним из 3х способов: > where substring(x,1,4)='blah' or substring(x,1,4)='foob' Не оптимизируется индексом > where substring(x,1,4) in ('blah', 'foob') Не оптимизируется индексом > where x like 'blah%' or x like 'foob%' ОПТИмизируется индексом > Кластеризации по полю x нет, так что с этой стороны у like нет премущества. Главное чтобы индекс был по этому полю. > Вопрос - будет ли какой-нибудь из 3х способов работать быстрее и почему? Вроде всё написал. Но лучше запросы целиком смотреть. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2010, 18:11 |
|
||
|
ASE 12.5 - поиск в строке, что быстрее?
|
|||
|---|---|---|---|
|
#18+
MasterZiv Kru пишет: > Есть запросы котором есть SARG по индексированному полю и есть SARG > ищущий в строке. > > Т.е поиск второго SARG будет осуществляться перебором записей в > страницах данных отобранных 1м SARG. Запросы целиком, пожалуйста. > Сам поиск в строке можно реализовать одним из 3х способов: > where substring(x,1,4)='blah' or substring(x,1,4)='foob' Не оптимизируется индексом > where substring(x,1,4) in ('blah', 'foob') Не оптимизируется индексом > where x like 'blah%' or x like 'foob%' ОПТИмизируется индексом > Кластеризации по полю x нет, так что с этой стороны у like нет премущества. Главное чтобы индекс был по этому полю. > Вопрос - будет ли какой-нибудь из 3х способов работать быстрее и почему? Вроде всё написал. Но лучше запросы целиком смотреть. Добрый день, MasterZiv, большое спасибо за ответ. Я извиняюсь, что в свою очередь отвечаю с задержкой - были разные запарки... Ниже пример Таблица с 2мя полями - одно числовое, 2е строковое. Индексы есть на обоих полях, но кластеризация по числовому полю. Далее я использую разные выражения для поиска по фрагменту строки, строю планы и замеряю статистику. Результаты, не зависимо от выражения получаются одинаковыми, хотя используемые операторы совершенно разные. В 3м тесте специально добавил пару значений с гораздо более высокой кардинальностью. Запросы тем не менее всё равно используют кластерный индекс, что в общем-то понятно... В общем-то ясно, что i/o не зависит от оператора, за исключением случаев когда на строковом поле кластерный индекс и используется like 'abc%'. Но... может всё-же быть разница в производительности заметная на большом объеме данных? Есть ли какая-нибудь возможность сравнить стоимость операторов? Заранее большое спасибо Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2010, 23:00 |
|
||
|
|

start [/forum/topic.php?fid=55&fpage=28&tid=2010635]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
52ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
42ms |
get tp. blocked users: |
2ms |
| others: | 13ms |
| total: | 153ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...