эффективность запроса для булевой записи

Question

У меня есть несколько таблиц с булевым столбцом, например. активный столбец, чтобы указать, является ли активным пользователем или нет, а затем запросить все неактивный пользователь я использую

select * from users where active = 0 

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

select * from orders where processed = 0 

Я рассматриваю добавление помощника таблицы для записи этих неактивных пользователей и необработанных заказов например,

CREATE TABLE IF NOT EXISTS failedRecord (tablename text, row integer) ; //row will be rowid 

Мне действительно не нравится это самодельное решение. Я предпочту использовать базу данных решений, но я не уверен, поможет ли использование индекса в булевом столбце или нет. B/C Я считаю, что индексы реализуются путем создания отдельной таблицы индексов, которая отображает ключ, созданный из столбца, в индекс строки в индексированной таблице. Для логического столбца, поскольку значение может быть только 0 или 1, я думал, что отображение не будет эффективным.

Я использую sqlite, но я предполагаю, что другая база данных также будет иметь проблему.

---

Обновлен мой вопрос.

Большинство моих пользователей являются активными, и большинство заказов обрабатываются, то есть в моем случае здесь только несколько строк равны 0, поэтому после того, как второй мыслительный индекс может быть эффективным. Это так?

Answer 1

Если большинство пользователей являются активными или обрабатываются большинство заказов, то очень мало строк совпадают, и вы можете ускорить второй запрос, индексируя столбец processed. (Если у вас SQLite 3.8.0 или новее, вы можете избежать индексирования обработанных заказов с помощью partial index.) Использование индекса намного быстрее и удобнее обслуживать, чем создавать вспомогательную таблицу вручную.

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

Answer 2

Я нахожу, что этот вопрос задавали и отвечали в списке рассылки sqlite Index on BOOLEAN field. Надеюсь, они правы.

Для цитирования: «Если все возможные значения одинаково распределены, и вы часто ищете определенное значение, индекс поможет, даже если у вас есть только два возможных значения. Если у вас есть почти все« 2011 »строки, а вы «вновь ищет„2011“, то индекс не поможет ...

на самом деле, безубыточности точка примерно 1/10: индекс помогает, если вы выбор 10% или меньше записей в таблице, в противном случае линейное сканирование будет быстрее ».

«Это может помочь тогда и только тогда, когда a) у вас есть еще много записей с FLAG = 1, чем с FLAG = 0 (или наоборот), и b) большую часть времени вы просматриваете записи, принадлежащие небольшое подмножество. Например, если имеется небольшое количество «активных» или последних записей, которые необходимо обработать, и большой архив «обработанных» записей.«