помогите оптимизировать sql-запрос

> 1 список строк в запросе порой получается огромным 2 это неистово жрет память (python3, apache, sqlite3)

Делать подзапрос, а не просто перечислять. И огромный это сколько?

create table emails(
    id int not null primary key,
    address varchar(30),
    sent bool,
    failcount int default 0
);

create unique index emails_address on emails(address);

create table task(email varchar(30));

insert into task values ('email1'); // Поместить вот так все строки ...
...
insert into task values('emailN'); // ... которые хотим обработать в этот цикл

foreach line in (
   select emails.* from tasks
   join emails
     on email.address = tasks.email and failcount < 5 and sent = 0
) {
   if (spame_sent(line["address"]) {
        update emails set failcount = failcount+1 where id = line["id"];
   } else {
        update emails set proceeded=1 where id = line["id"];
   }
}

/thread

>>Делать подзапрос, а не просто перечислять

не понимаю, какой подзапрос?

И огромный это сколько?

заранее неизвестно. но вполне может быть и 6000 символов
главное что это точно сжирает память

во первых «перечисляем все строки через запятую» корявит скорость. Если не нужен поиск по подстрокам(а только сравнения равно/не-равно), то можно дополнительно положить в базу хеш от строк и их сравнивать и индексировать (для sqlite совершенно точно).

во вторых вариант с доп.таблицей уже предложен и работать должен шустро.

если доп.таблица не подходит по идеалогии, то переложите часть работы на приложение; «where data in (...)» на прикладных хеш-таблицах в некоторых случаях эффективнее.

Сделай столбец со строкой индексированный. и для каждой строки из файла делай select * from rows where str=$str and fails > 5

Не забывай открывать тразакцию sqlite сразу после открытия файла, а закрывай её после (или перед..) закрытием файла. Если этого не делать - то транзакция открывается и закрывается на каждый стейтмент.

И да, используй prepare/execute

Будет ОЧЕНЬ быстро.

класть в базу хеш - не очень хорошее решение. эскулайт и сам справится с этой задачей когда будет делать индекс.

Сравнение равно-неравно чисто по хешу не может дать точный результат из-за потенциальных коллизий хеша.

Сравнение равно-неравно чисто по хешу не может дать точный результат из-за потенциальных коллизий хеша.

смотри

переложите часть работы на приложение; «where data in (...)» на прикладных хеш-таблицах

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

хотя штука тонкая, без понятия что там у ТС за база (объёмы/запросы/варианты использования) дать 100% рецепт невозможно. Более чем вероятно что те строки что ТС сравнивает можно легко класть в отдельную таблицу и оперировать их индексами.

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

заранее просчитанные хеши/свёртки работают быстрее. Хотя и могут приводить к коллизиям.