100-1000 раз, то проект ооочень надолго задумывается. Что можно предпринять или что нужно поменять, при условии что заранее неизвестно сколько будет итераций? Может метод или запрос неверные?
Поздрааляю, ты столкнулся с потребностью оптимизировать нагрузку на БД) Это очень частая штука. Select * - означает что мы выбираем всю таблицу, и время выполнения (time complexity) будет n^2 Наша задача уменьшить время выполнения до lg n или n. Мы не хотим читать всю таблицу каждый раз, поэтому делаем индекс. Он будет бинарным деревом с временной сложностью lg n Профит https://sqlite.org/lang_createindex.html https://sqlite.org/faq.html#q19
Спасибо) Добавлю индекс.
Вот, кстати, запрос создания таблицы CREATE TABLE states ( uid INTEGER NOT NULL UNIQUE, data BLOB, PRIMARY KEY(`uid`) ); Индекс я тут вроде как создаю для uid.
Попробуй поэкспериментиповать с CREATE INDEX Будет ли разница
Не надо. Потому что не будет разницы
Попробуйте вместо вызова 100 раз, вызвать один раз, но достать 100 строк Используя, например, where uid in
Как только мы сделали SELECT *... это уже lg n, как минимум Сохранили в переменную и пошли перебирать , это еще n (Lg n) + n = n Получается линейное время, не квадратичное Точняк
Да, про N^2 ты подзагнул...
Я для этого здесь и пишу) Шоб разобраться)
Ну, написали уже, из одной таблицы макс. будет линейная выборка.
> Вообще-то индексы бывают не только деревянными, есть классический хэш ты про тот кусок кода говоришь или вообще по жизни? Там четко selection * ... > lg n + m, где m, вероятнее всего, равняется одному или на порядки меньше n Здесь нету m, там в кусочке кода мы все элементы которые выбрали перебираем, поэтому m = n
Обсуждают сегодня