"Продукт" - это громко сказано, скорее - проверка одной идеи. Поэтому предложить "потенциальным клиентам" пока нечего, не знаю как уж их заинтересовать. Количество записей точно сказать не могу, т.к. не известно из скольких записей получится выявить необходимые паттерны. Но если бы, например, было бы по несколько десятков (а лучше сотня) записей с: разгневанными клиентами, довольными клиентами, купившими клиентами, не купившими клиентами и т.п., то уже было бы с чем работать.
делать "расческу" или как оно там называется никак нельзя, т.к. в примере указана простая таблица, на практике же, выборка проходит с сортировкой и фильтрацией, так что реальные id идут вперемешку, кроме того велика вероятность окончания процесса с ошибкой, так что захваченные строки останутся не обработанными и придется частенько запускать обнуление счетчика max_id, для повторного прохода
ок, давай так:
CREATE TABLE test.foo (
id int(11) NOT NULL AUTO_INCREMENT,
title varchar(255) DEFAULT NULL,
PRIMARY KEY (id)
)
ENGINE = INNODB
INSERT iN TO test.foo SET title = 'title1';
INSERT iN TO test.foo SET title = 'title2';
INSERT iN TO test.foo SET title = 'title3';
INSERT iN TO test.foo SET title = 'title4';
открываем две консоли, заходим в mysql, и выполняем в обеих такое:
begin; select * from foo limit 2 for update; select sleep(5); commit;
Результат: 1 консоль
+----+--------+
| id | title |
+----+--------+
| 1 | title1 |
| 2 | title2 |
+----+--------+
3 rows in set (0.00 sec)
+----------+
| sleep(5) |
+----------+
| 0 |
+----------+
1 row in set (5.00 sec)
Вторая консоль ждет несколько секунд и ...
Результат: 2 консоль
+----+--------+
| id | title |
+----+--------+
| 1 | title1 |
| 2 | title2 |
+----+--------+
3 rows in set (4.04 sec)
+----------+
| sleep(5) |
+----------+
| 0 |
+----------+
1 row in set (5.00 sec)
Query OK, 0 rows affected (0.00 sec)
Вывод:
второй процесс ждет завершение первой транзакции
как же тогда решается вопрос параллельности? например в postgresql можно решить через pg_try_advisory_lock() и pg_advisory_unlock() - хотя не очень надежно
Вот все индексы:
INDEX domainCreated_updatedAt (domain_created, updated_at),
INDEX Status_Proc_dCreated (status, proc, domain_created, updated_at),
INDEX UpdatedAt_Status (updated_at, status)
status, proc можно взять из второго, а domain_created, updated_at - из первого, хотя EXPLAIN SELECT показывает только Status_Proc_dCreated
