Сообщение от h1dd3n
В "хорошем случае с индексом":
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 раз больше.
|
Это же очевидно что не будет общее время в 10 раз больше.
Где было сказано что время работы будет в 10 раз больше? Там есть overhead на сам запрос по себе.
Сообщение от h1dd3n
В "плохом случае без индексов":
SELECT * FROM some_table WHERE id in [1,2,3,4,5,6,7,8,9,10]
- 10 раз full_scan
|
Твое заключение говорит что ты нихера не читаешь что я пишу. Не будет 10 раз full_scan в хорошем случае. Потому что можно сделать временный индекс по массиву данных переданных в запросе (IN), и один full_scan с проверкой по временному индексу. И я третий раз повторюсь: это при хорошей реализации дб движка.
Сообщение от h1dd3n
SELECT * FROM some_table WHERE id = 1
- 1 раз full_scan
объем работы снова в 10 раз больше.
Но ведь ты написал что в 10 раз больше когда "И это в хорошем случае когда индексы используются", в плохом соответственно время должно быть более чем 10 раз больше. Как же так ? (правильный ответ: мока балабол)
|
Когда индекс юзается, то бъет прямо по индексу, когда не юзается, может быть 10 full_scan'ов O(a*b), а может быть один с мелким индексом O(a + b).
Но ты любишь спорить, продолжай.
Сообщение от h1dd3n
Есть таблица, с колонкой name (индекса нету). В таблице 100000 записей. Я делаю следующий запрос:
SELECT * FROM some_table WHERE name IN [...],
где в in "закидываю" 250 имен. Какой "индекс" по твоему должен построить БД, и по каким данным ?
Даже ослу понятно что когда анализатор запроса видит in, то он парсит его не в массив, а в hashset, по которому поиск быстрый (ведь данные то отсортированы). Но никакого "индекса" он для этого не делает.
Никаких
"легковесных индексов" там нету, более того если на вход пришло [5,2,3,2], то hashset который создасть mysql будет [2,3,5], то есть памяти даже меньше чем было бы если бы mysql не делал hashset. И ни при каких обстоятельствах там не будет больше потреблено памяти из-за "временных индексов", просто набор данных принятых в in будет отсортирован (объем памяти останется тот же).
|
Лол.
Временный индекс === hashset === dict...
Терминология "индексация" (основываюсь на общении с англо-говорящими разработчиками) - значит создать hashset, dict, object, назови-свой, любой метод создания ассоциативных массивов (хэш таблиц).
У тебя пукан взрывается лишь по причине что ты термин не уточнил?
Сообщение от h1dd3n
Ну и наконец, то что ты как всегда проигнорировал:
Что же такое O(a*b) и O(a+b) ?? Это вычислительная сложность / big o notation? |
Ты вроде же умного строишь из себя, а bit O notation в первый раз видишь?
Да и ты по теме чем помоги, а не офтопь..