Ответ: [MySql] Оператор сравнения IN
Цитата:
будет в 10 раз быстрее чем SELECT * FROM some_table WHERE id IN [1, 5, 7] ?? херню понаписал как всегда. Цитата:
Во-вторых, какие еще временные индексы ? По твоему мнению по каким данным база должна построить "временный индекс" ?? Приведи пример запроса (с IN, разумеется) в котором использование этого самого "временного индекса" даст преимущество. Цитата:
|
Ответ: [MySql] Оператор сравнения IN
Цитата:
Я сравниваю: SELECT * FROM some_table WHERE id IN [1, 5, 7] И SELECT * FROM some_table WHERE id = 1 В данном запросе, тут прямой hit по индексу. А если поле не проиндексировано и не уникально, и у тебя 100 записей. То будет O(a*b) либо O(a + b). В зависимости как реализован поиск, с или без временного индекса. Цитата:
Попробуй создай array и map данных, и напиши мелкий поиск по ним с IN функционалом на предпочитаемом языке. И посмотри на проблемы и скорости. |
Ответ: [MySql] Оператор сравнения IN
Цитата:
SELECT * FROM some_table WHERE id in [1,2,3,4,5,6,7,8,9,10] - 10 поисков по индексу SELECT * FROM some_table WHERE id = 1 - 1 поиск по индексу объем работы в первом случае в 10 раз больше, что, кстати, нихрена не означает что время выполнения запроса в целом будет в 10 раз больше. В "плохом случае без индексов": SELECT * FROM some_table WHERE id in [1,2,3,4,5,6,7,8,9,10] - 10 раз full_scan SELECT * FROM some_table WHERE id = 1 - 1 раз full_scan объем работы снова в 10 раз больше. Но ведь ты написал что в 10 раз больше когда "И это в хорошем случае когда индексы используются", в плохом соответственно время должно быть более чем 10 раз больше. Как же так ? (правильный ответ: мока балабол) ------------------ Цитата:
Есть таблица, с колонкой name (индекса нету). В таблице 100000 записей. Я делаю следующий запрос: SELECT * FROM some_table WHERE name IN [...], где в in "закидываю" 250 имен. Какой "индекс" по твоему должен построить БД, и по каким данным ? Даже ослу понятно что когда анализатор запроса видит in, то он парсит его не в массив, а в hashset, по которому поиск быстрый (ведь данные то отсортированы). Но никакого "индекса" он для этого не делает. Никаких Цитата:
---------------- Ну и наконец, то что ты как всегда проигнорировал: Что же такое O(a*b) и O(a+b) ?? Это вычислительная сложность / big o notation? |
Ответ: [MySql] Оператор сравнения IN
Цитата:
Где было сказано что время работы будет в 10 раз больше? Там есть overhead на сам запрос по себе. Цитата:
Цитата:
Но ты любишь спорить, продолжай. Цитата:
Временный индекс === hashset === dict... Терминология "индексация" (основываюсь на общении с англо-говорящими разработчиками) - значит создать hashset, dict, object, назови-свой, любой метод создания ассоциативных массивов (хэш таблиц). У тебя пукан взрывается лишь по причине что ты термин не уточнил? Цитата:
Да и ты по теме чем помоги, а не офтопь.. |
Ответ: [MySql] Оператор сравнения IN
Цитата:
Во-вторых, очевидно предыдущий пост ты прочитать не можешь (видимо слишком сложно), где я написал какую конкретно структуру "строит" mysql, и почему на самом деле там никаких структур не строится, а входной массив просто сортируется и все. Если при этом удаляются повторяющиеся элементы, то тогда это уже не массив, а сет (т.к. в сете нет повторений по определению). Dictionary, Hashset и отсортированный массив 3 разные структуры и нигде между ними нельзя поставить === (надеюсь это для тебя понять будет не слишком сложно). В этой твой англоязычной терминологии индексация - создание ассоциативного массива (как ты сам сказал), но ни 1 база (в т.ч. mysql) для быстрого поиска по данным в IN ассоциативный массив не строит. Нужно объяснять почему ? А стоп, я же уже объяснил в пред. посте, только вот ты просто не прочитал (или намеренно дурачка строишь). Следственно ты просто сморозил херню. Цитата:
Прямо в тексте который ты процитировал написано в плохом случае будет 10 фулсканов, а ты дальше пишешь мне что в хорошем случае 10 фулсканов не будет, а где собственно я писал что в хорошем случае будет 10 фулсканов (конкретную цитату приведи)?. Цитата:
Во-вторых O(a*b) и O(a+b) это не big o notation и абсолютно никакого отношения к нему не имеет. Далее чтобы наконец убедится в твоем полном непонимании big o notation, ответь на 3 вопроса: Какова "сложность" алгоритма который пробегает весь объем данных 2 раза (всегда)? Какова "сложность" алгоритма который пробегает весь объем данных 10 раз (всегда)? Равны ли "сложности" этих алгоритмов и если нет, то какой "сложнее" ? |
Ответ: [MySql] Оператор сравнения IN
Слушай h1dd3n, тебе скучно и учить некого? Иди детей своих учить.
Что ты пишешь очевидные вещи, и мне просто в падлу расписывать детали. Это задача каждого разраба самому этим интересоваться. Дали вопрос, я в общих чертах описал как и что, и описал корректно, т.к. твои все "правки" не противоречат моим убеждениям. Следственно я не понимаю чего ты распинаешься. Цитата:
И если у тебя с англ. плохо, уж прости, но основной % всей культуры разработчиков - основана на англ. языке, deal with it. Цитата:
И сортированный массив ты вообще от куда вытащил? Dictionary и Hashset и Object (js) объеденяет одно - возможность доступа к элементу по key'ю. И на этой основе я их объеденил, т.к. для решения задачи построения временного индекса - нужно именно это свойство. Цитата:
Цитата:
Бля чувак, мне впадлу с тобой спорить. Тратишь свое и мое время. Обзывания в мой адрес - ок. Че ты доказываешь? Если хочешь поделиться инфой, кинь мне ссылочки на доки по теме, я почитаю. В реальности, я пахаю и у меня много опыта, работая с кучей разных разрабов, и куча разного опыта. Никто так не залупился как ты, и со всеми нахожу общий метод общения, важно не придираться к словам, а доносить идею, и если что-то не ясно, то способствуешь друг-другу в уточнении данных. Это называется общение, и обмен информацией. Если тебе хочется с кем-то спорить и чето там доказывать, иди к кому-то другому. Ты давно показал степень невежества по разным темам на булке, я к тебе интереса не испытываю, и думаю тебе стоит "охладеть" ко мне тоже. |
Ответ: [MySql] Оператор сравнения IN
Цитата:
Цитата:
Hashset в C# не хранит данные как ассоциативный массив. Для решения задачи быстрого поиска по данным в IN не нужен ассоциативный массив, не нужен там доступ по ключу (выделю шрифтом побольше чтобы ты заметил) Повторю еще раз - массив просто сортируется, и все. Это не hashset. Это не dictionary. Это не object из js. Это просто отсортированный массив. Разница при этом большая - ведь объем памяти остается точно такой же как если бы массив и не сортировался бы (то есть разницы в объеме памяти между вариантом с "временным индексом (c) moka" и без него нету никакой). В то время как ты сказал что "индексы обычно легковесные" (несколько постов назад). Тем самым ты дезинформировал всех кто прочитал твой пост, ведь объем памяти данных которые были в IN при так называемой "индексации (с) moka" не изменится (а возможно даже станет меньше, если есть повторения), что прямо противоречит тому что ты сказал про легковесные индексы. Цитата:
Нет никакого "прямого доступа". Hashset просто хранит вместо отсортированных данных, отсортированные хэши этих данных То есть не SORT (["apple", "google", "banana"]), а SORT ([ HASH("apple"), HASH("google"), HASH("banana) ]). Зачем так ? Да для того чтобы быстрее искать. Если у тебя массив чисел ([1,5,3]) то hashset будет работать также быстро как и если бы ты искал по отсортированному массиву. Но вот если у тебя массив строк, то будет оптимальнее хранить хэши этих строк, ведь: 1. Меньше памяти на хранение 2. Сравнение 2 хэшей скорее всего быстрее, ведь например если хэш это число (int32) то сравнение 2 чисел это 3 процессорных инструкции (то есть быстро), а вот каждый раз строки сравнивать это медленно. Понятно ? Или еще в каком то моменте подробнее объяснить надо ? -------- В данной ситуации мы "общаемся" на форуме, и если ты прямо озвучил утверждение которое было ложным/не корректным, то я могу свободно указать тебе на это, приведя аргументы/доводы (что я и сделал). Ну и наконец ты так и не ответил про Big o notation. Ты же очень умный и опыта у тебя дохера, так ответь же мне ничего не понимающему любящему поспорить человеку на 3 вопроса (для такого гуру как ты это не составит никакого труда): Какова "сложность" алгоритма который пробегает весь объем данных 2 раза (всегда)? Какова "сложность" алгоритма который пробегает весь объем данных 10 раз (всегда)? Равны ли "сложности" этих алгоритмов и если нет, то какой "сложнее" ? |
Часовой пояс GMT +4, время: 02:51. |
vBulletin® Version 3.6.5.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot