|
|
|
Индекс не на первые буквы, а на последние
|
|||
|---|---|---|---|
|
#18+
Код: sql 1. Код: plaintext 1. 2. 3. 4. Мы знаем, что если на эти данные кинуть индекс alter t add index _tit (tit(8)), то он окажется полностью бесполезен потому что во всех первых 8 буквах у нас одинаковый контент. Вопрос: существует ли возможность кинуть индекс на те же самые 8 букв, но не с начала, а с конца строки? Сейчас у нас на like '%Саша' индексы не целяются, а на like 'Саша%' цепляются. А если бы можно было сделать индекс с конца, то наверное у нас на like 'Саша%' индекс перестал бы цепляться, а на like '%Саша' начал бы цепляться. Или в таких случаях проще на клиенте флапануть данные и хранить их флипанутыми и флипануто же искать? Код: plaintext 1. 2. 3. 4. А искать так Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2015, 20:34:19 |
|
||
|
Индекс не на первые буквы, а на последние
|
|||
|---|---|---|---|
|
#18+
Lumix Код: sql 1. Код: plaintext 1. 2. 3. 4. Мы знаем, что если на эти данные кинуть индекс alter t add index _tit (tit(8)), то он окажется полностью бесполезен потому что во всех первых 8 буквах у нас одинаковый контент. Нет, не будет он полностью бесполезен. Он будет бесполезен только если во всей таблице будет у всех строк поле tit начинаться с этой одной и той же строки -- "Кто дурак?" LumixВопрос: существует ли возможность кинуть индекс на те же самые 8 букв, но не с начала, а с конца строки? В принципе -- да. В MySQL -- нет. Потому что такой индекс должен быть на выражение -- перевёрнутую строку (возможно, с префиксом). Но можно это достаточно легко обойти (с небольшими потерями) -- сделать ещё одно поле, где хранить данную строку в перевёрнутом виде. А вот некоторые другие СУБД могут индексы делать по выражениям -- оракл, например. LumixСейчас у нас на like '%Саша' индексы не целяются, а на like 'Саша%' цепляются. А если бы можно было сделать индекс с конца, то наверное у нас на like 'Саша%' индекс перестал бы цепляться, а на like '%Саша' начал бы цепляться. Нет, тоже надо было бы писать rev_tit like 'ашаС%' LumixИли в таких случаях проще на клиенте флапануть данные и хранить их флипанутыми и флипануто же искать? Ну, не обязательно, но можно и на клиенте. А можно в БД, триггером или процедурой формировать это второе поле. Lumix Код: plaintext 1. 2. 3. 4. А искать так Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2015, 21:26:59 |
|
||
|
Индекс не на первые буквы, а на последние
|
|||
|---|---|---|---|
|
#18+
понятно, что индексы когда учавствуют хорошо но насколько это будет быстрее? у меня p like %xxx% and p like %xxx% ищет и без таких замоочек быстро - 28 000 записей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2015, 21:55:14 |
|
||
|
Индекс не на первые буквы, а на последние
|
|||
|---|---|---|---|
|
#18+
MasterZivА вот некоторые другие СУБД могут индексы делать по выражениям -- оракл, например.Читал, что в версии 5.7 ожидается что-то такое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2015, 22:02:13 |
|
||
|
Индекс не на первые буквы, а на последние
|
|||
|---|---|---|---|
|
#18+
MasterZiv, огромное спасибо за ответ! вадяпонятно, что индексы когда учавствуют хорошо но насколько это будет быстрее? у меня p like %xxx% and p like %xxx% ищет и без таких замоочек быстро - 28 000 записей Насколько я помню любая вилкарда в самом начале полностью сводит на нет любое использование индексов. Гляньте explain. Скорее всего, для колонки p индексы там не используются вообще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2015, 22:21:02 |
|
||
|
Индекс не на первые буквы, а на последние
|
|||
|---|---|---|---|
|
#18+
авторНасколько я помню любая вилкарда в самом начале полностью сводит на нет любое использование индексов. Гляньте explain. Скорее всего, для колонки p индексы там не используются вообще. дак и я о том же. но скорость от этого не страдает, причем я говорю о времени всей системы - от ввода символа на клиенте(в браузере) до появления данных на клиенте(в браузере). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2015, 22:28:05 |
|
||
|
Индекс не на первые буквы, а на последние
|
|||
|---|---|---|---|
|
#18+
вадяно скорость от этого не страдаета чему там страдать на 28000 записей? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2015, 07:19:45 |
|
||
|
Индекс не на первые буквы, а на последние
|
|||
|---|---|---|---|
|
#18+
вадяпонятно, что индексы когда учавствуют хорошо но насколько это будет быстрее? у меня p like %xxx% and p like %xxx% ищет и без таких замоочек быстро - 28 000 записей это как раз потому что записей не так много. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2015, 07:35:31 |
|
||
|
Индекс не на первые буквы, а на последние
|
|||
|---|---|---|---|
|
#18+
LumixMasterZiv, огромное спасибо за ответ! вадяпонятно, что индексы когда учавствуют хорошо но насколько это будет быстрее? у меня p like %xxx% and p like %xxx% ищет и без таких замоочек быстро - 28 000 записей Насколько я помню любая вилкарда в самом начале полностью сводит на нет любое использование индексов. Гляньте explain. Скорее всего, для колонки p индексы там не используются вообще. не любая. field like 'prefix%' будет отлично работать, особенно если префикс длинный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2015, 07:38:08 |
|
||
|
Индекс не на первые буквы, а на последние
|
|||
|---|---|---|---|
|
#18+
MasterZivвадяпонятно, что индексы когда учавствуют хорошо но насколько это будет быстрее? у меня p like %xxx% and p like %xxx% ищет и без таких замоочек быстро - 28 000 записей это как раз потому что записей не так много. я догадываюсь , что все они влазят в кэш, но и 70 000работало быстро. вопрос - с каким количеством будут тормоза? если сейчас что-то оптимизировать - просто не увидишь какой из оптимизированных вариантов будет нести реальную пользу. 28 000 - рельные наименования товара оптовой конторы за приличное время работы конторы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2015, 07:53:19 |
|
||
|
Индекс не на первые буквы, а на последние
|
|||
|---|---|---|---|
|
#18+
вадяя догадываюсь , что все они влазят в кэш, но и 70 000работало быстро. вопрос - с каким количеством будут тормоза?С тем, когда перестанет укладываться в порог терпения ваших пользователей. До тех пор, пока таблица влазит в кэш и достаточно долго не вымывается оттуда, рост времени выполнения такого рода запроса будет линейным от роста объема данных. Условно говоря, если сейчас выборка происходит за 100 мс, то при 70000 записей она будет происходить за 250-300 мс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2015, 10:02:04 |
|
||
|
Индекс не на первые буквы, а на последние
|
|||
|---|---|---|---|
|
#18+
[quot вадя]MasterZivпропущено... это как раз потому что записей не так много. я догадываюсь , что все они влазят в кэш, но и 70 000работало быстро. вопрос - с каким количеством будут тормоза? Ну вообще-то это всё зависит от всяких параметров, но сотни тысяч или миллионы уже точно не будут быстро работать. если сейчас что-то оптимизировать - просто не увидишь какой из оптимизированных вариантов будет нести реальную пользу. Это да, золотое правило: работает -- не трогай. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2015, 10:41:42 |
|
||
|
Индекс не на первые буквы, а на последние
|
|||
|---|---|---|---|
|
#18+
MasterZiv Нет, не будет он полностью бесполезен. Он будет бесполезен только если во всей таблице будет у всех строк поле tit начинаться с этой одной и той же строки -- "Кто дурак?" Вообще то, он хотел сказать, что только в этом случае и будет полезен . Если вы используете "устаревший" myisam. Там строковые ключи пакуются. А в innodb нет. Вывод - надо запретить innodb. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2015, 20:19:32 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=39080701&tid=1832592]: |
0ms |
get settings: |
7ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
38ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
37ms |
get tp. blocked users: |
1ms |
| others: | 257ms |
| total: | 364ms |

| 0 / 0 |
