Как оптимизировать удаление с диапазоном дат, где предложение? - PullRequest
0 голосов
/ 14 июля 2010

Я создал приложение для Android, и есть функция, которая будет периодически удалять старые записи

delete from tablea where col1 = 'value1' and col2 = 'value2' and postdate < '2010-06-14'

У него проблемы с производительностью, когда общее количество строк в таблице превышает 50 000.Для удаления 500 записей требуется около 45 секунд.

У меня уже есть индекс для этого предложения where:

CREATE INDEX indexa on tablea (col1, col2, postdate)

Добавление PRAGMA синхронного = OFF и PRAGMA count_changes = OFF не помогло.

Пожалуйста, сообщите

Ответы [ 2 ]

1 голос
/ 14 июля 2010

Проверьте тип поля постдаты. SELECT typeof(postdate). Похоже, что SQLite будет обрабатывать его как TEXT, основываясь на предложении where. SQLite не имеет понятия типа «дата», только сходство NUMERIC должно произойти для любых «дат». Если вы не вставляете NUMERIC s, то, вероятно, он выполняет сравнение строк, и это будет медленнее, чем ожидаемые целочисленные сравнения. Если вы вставляете NUMERIC s, тогда условие where может вызывать их приведение сначала к TEXT, а затем к критерию предложения where.

Вы можете ознакомиться с документацией о типах данных .

0 голосов
/ 14 июля 2010

Мне кажется, что ваш индекс бесполезен, как написано.Я думаю, вы захотите:

CREATE INDEX indexa on tablea (col1, col2)
CREATE INDEX indexb on tablea (postdate)

Как я прочитал, моя интерпретация документации говорит о том, что для определения того, какая строка упоминается в вашем примере, в базе данных должна быть указана конкретная датазаданная пара значений (чтобы можно было искать индекс / индексы).У вас нет конкретной даты.Вместо этого вы ищете диапазон значений даты.

Проблема заключается в том, что сопоставляемость значений дат включена в индекс комбинации, который вы создали, поэтому вы не можете получить эту информацию очень легко, что делает индекс ограниченным.

Конечно, я мог быть полон этого.Мой основной опыт не с sqlite.Тем не менее, это не должно быть больно, чтобы попробовать выше.

...