MySQL нумерация записей по группам - ударил ли я ошибку?

Question

Я пытаюсь записать некоторые записи в MySQL (5.5.44-0 на Ubuntu), сгруппированные по другому столбцу (вы увидите, что я имею в виду ниже). Я адаптирую решение, описанное в Running Sums for Multiple Categories in MySQL, за исключением того, что я просто нумерую, а не суммирую.

Приведенные таблицы довольно огромны с почти 100 столбцами, поэтому давайте сначала упростим демонстрацию, создав производные таблицы только с важными столбцами. Извиняюсь за не разделяя SQL скрипку, потому что она не выглядит, как будто это воспроизводимой, если не сделано с большим объемом данных, которые я не могу поделиться:

Создание таблиц:

CREATE TABLE `inquiries_test` (
    `id` int(11) NOT NULL DEFAULT '0', 
    `motive` varchar(255) CHARACTER SET utf8 DEFAULT NULL, 
    PRIMARY KEY (`inquiry_id`), 
    KEY `motive` (`motive`) 
); 

insert into inquires_test select id, motive from inquiries; 

CREATE TABLE `leads_test` (
    `lead_id` int(11) DEFAULT NULL, 
    `created_at` datetime DEFAULT NULL, 
    `inquiry_id` int(11) DEFAULT NULL, 
    KEY `id` (`lead_id`) 
); 

insert into leads_test select lead_id, created_at, inquiry_id; 

CREATE TABLE `lead_inserts` (
    `lead_id` int(11) DEFAULT NULL, 
    `created_at` datetime DEFAULT NULL, 
    `cnt` int(11) DEFAULT NULL 
); 

Вы заметите выше, что данные fromquiries_test и lead_test поступают из фактических производственных таблиц. Важность этого придет позже. Теперь заселение lead_inserts:

playground>insert into lead_inserts (cnt, created_at, lead_id) 
    -> SELECT @cnt := if(@id = l.lead_id,@cnt,0) + 1 as cnt 
    -> , l.created_at 
    -> , @id := l.lead_id as local_resouce_id 
    -> FROM leads_test l join inquiries_test i on (l.inquiry_id=i.id) 
    -> CROSS JOIN (select @id := 0, @cnt := 0) as InitVarsAlias 
    -> where i.motive='real' ORDER BY lead_id, created_at; 
Query OK, 2172774 rows affected (14.30 sec) 
Records: 2172774 Duplicates: 0 Warnings: 0 

playground>select * from lead_inserts where lead_id in (117,118); 
+---------+---------------------+------+ 
| lead_id | created_at   | cnt | 
+---------+---------------------+------+ 
|  117 | 2012-06-23 00:13:09 | 1 | 
|  117 | 2014-09-14 04:30:37 | 2 | 
|  117 | 2015-01-27 22:34:41 | 3 | 
|  117 | 2015-03-19 19:33:51 | 4 | 
|  118 | 2014-12-24 17:47:15 | 1 | 
|  118 | 2015-01-23 21:30:09 | 2 | 
|  118 | 2015-04-07 21:33:43 | 3 | 
|  118 | 2015-04-10 17:00:04 | 4 | 
|  118 | 2015-05-12 21:59:49 | 5 | 
+---------+---------------------+------+ 

До сих пор так хорошо - значение CNT «перезагрузки» для каждого нового lead_id. Теперь, учитывая, что test_test и inquiries_tests в основном ведут и запросы с удалением других столбцов, имеет смысл ожидать, что если я изменю инструкцию insert для использования исходных таблиц, результат должен быть таким же, не так ли? Но посмотрите:

playground>truncate table lead_inserts; 
Query OK, 0 rows affected (0.14 sec) 

playground>insert into lead_inserts (cnt, created_at, lead_id) 
    -> SELECT @cnt := if(@id = l.lead_id,@cnt,0) + 1 as cnt 
    -> , l.created_at 
    -> , @id := l.lead_id as local_resouce_id 
    -> FROM leads l join inquiries i on (l.inquiry_id=i.id)   
    -> CROSS JOIN (select @id := 0, @cnt := 0) as InitVarsAlias 
    -> where i.motive='real' ORDER BY lead_id, created_at; 
Query OK, 2172774 rows affected (17.25 sec) 
Records: 2172774 Duplicates: 0 Warnings: 0 

playground>select * from lead_inserts where lead_id in (117,118); 
+---------+---------------------+------+ 
| lead_id | created_at   | cnt | 
+---------+---------------------+------+ 
|  117 | 2012-06-23 00:13:09 | 1 | 
|  117 | 2014-09-14 04:30:37 | 1 | 
|  117 | 2015-01-27 22:34:41 | 1 | 
|  117 | 2015-03-19 19:33:51 | 1 | 
|  118 | 2014-12-24 17:47:15 | 1 | 
|  118 | 2015-01-23 21:30:09 | 1 | 
|  118 | 2015-04-07 21:33:43 | 1 | 
|  118 | 2015-04-10 17:00:04 | 1 | 
|  118 | 2015-05-12 21:59:49 | 1 | 
+---------+---------------------+------+ 

Что произошло с нумерацией? Другие наблюдения при использовании исходных таблиц:

1. Если я не обрабатываю все записи и не укажу только несколько lead_id, вычисление выходит правильно.
2. Если я удаляю предложение INSERT и запускаю его как select (с предложением LIMIT, чтобы показать только 50 строк), вычисление выходит правильно.

Итак, это ошибка, которую я ударил, или я что-то упустил? В реальной жизни я не могу использовать этот процесс в качестве обходного пути - мне действительно нужно использовать запросы и запросы, потому что из этих таблиц есть другие столбцы, которые должны быть частью lead_inserts.

Спасибо!

Answer 1

A Cha указал, что это оптимизация MySQL, где MySQL не находит оснований для выполнения ORDER BY, когда конечный результат будет просто вставлен в новую таблицу. Почему он работает для тестовых таблиц, а не для производственных, когда у них одинаковое количество строк, я не знаю. Но это, как я заставил его разобраться, что буду вставлено:

Сначала убедитесь, что есть сцепленный индекс для столбцов Я Сортировать по:

CREATE INDEX idx_leads_lead_id_created ON leads(lead_id, created_at); 

Затем заставить MySQL использовать этот индекс:

insert into lead_inserts (cnt, created_at, lead_id) 
SELECT @cnt := if(@id = l.lead_id,@cnt,0) + 1 as cnt 
, l.created_at 
@id := l.lead_id as local_resouce_id 
FROM leads l FORCE INDEX FOR ORDER BY (idx_leads_lead_id_created) 
JOIN inquiries i on (l.inquiry_id=i.id)   
CROSS JOIN (select @id := 0, @cnt := 0) as InitVarsAlias 
WHERE i.motive='real' 
ORDER BY lead_id, created_at;