mySql. Долго выполняется запрос из-за фазы Sending data #657959

В очередной раз пытаюсь оптимизировать запрос, наткнулся на странную вещь. Немного поэкспериментировав, получил такой запрос: В профайлинге: И если увеличивать внутренний лимит до 10+млн, фаза Sending data растягивается на 5 минут. О какой передаче данных идёт речь? Если выбирать из таблицы напрямую, то фаза эта будет занимать считанные доли секунд.

Ап

получаешь через fetchall?

вообще уже давно надо было понять, что внутренний селект у тебя тебе нафиг не нужен

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

запроса

Что это? Запрос тестовый - разбирался откуда берётся Sending data.  В последнем предложении указал, что делал и без внутреннего селекта (т.е. это очевидно, что можно и без него)

сделай EXPLAIN твойзапрос

Есть же Executing.. Да и без внутреннего запроса Sending data вообще исчезает (сейчас проверил)

Вот..

А вот для прямого запроса (запрос есть в скрине):

вот, например: EXPLAIN SELECT score, distance, date, nickname FROM ( SELECT score, distance, date, nickname FROM jsgleest_results ORDER BY id DESC LIMIT 1000 ) AS innerSelect ORDER BY score DESC LIMIT 10 1    PRIMARY    <derived2>    ALL    NULL    NULL    NULL    NULL    1000    Using filesort 2    DERIVED    jsgleest_results    ALL    NULL    NULL    NULL    NULL    13283    Using filesort против EXPLAIN SELECT score, distance, date, nickname FROM ( SELECT score, distance, date, nickname FROM jsgleest_results WHERE id > ( SELECT Count( * ) -1000 FROM jsgleest_results ) ) AS innerSelect ORDER BY score DESC LIMIT 10 1    PRIMARY    <derived2>    ALL    NULL    NULL    NULL    NULL    1016    Using filesort 2    DERIVED    jsgleest_results    ALL    PRIMARY    NULL    NULL    NULL    13283    Using where 3    SUBQUERY    NULL    NULL    NULL    NULL    NULL    NULL    NULL    Select tables optimized away в первом случае - читается вся таблица, сортируется и уже из результатов выбирается 1000 первых, из них - выбирается 10 по другому условию. во втором - получается 1000 по первичному ключу, что на большом количестве данных быстрее

давай картинки целиком, а то вообще непонятно.

Это експлейн для запроса из . Больше в таблице ничего нет

ну так он у тебя 16 миллионов строк колбасит

просто запрос из лишен смысла - он у тебя равнозначен SELECT            owner_id      FROM            audio      LIMIT            10 только без индекса

Так вопрос про Sending data, а не про запрос. Что он куда отправляет?

я ж говорю - пока запрос выполняется - сендинг дата считается

а повторы есть?

Выполнение запроса - это Executing (сендинг дата нет в прямом запросе) Нет, все разные (строки разные, но owner_id есть одинаковые. Но суть опять же в сендинг дата)

.1 еще раз. в твоем случае - это чтение 16 мегастрок для последующего запроса. Так понятнее?

мехматовцев позорят. да исчо МГУ! грусть

Если это чтение, то понятно) Спасибо Ахаха Что грусть то (кроме твоей логики(? Как вообще МГУ и мускуль связаны?

да у тебя все ветки одинаковые, и при этом одинаково странные с одинаково малосмысленными запросами

Ветки одинаковые только из-за наличия скуля? Везде разные вопросы. А запрос я однажды выкладывал полный - помощи ноль было - поэтому приходится всё по частям разбирать

нет, ветки одинаковые из-за того, что у тебя все время запрос селект фром (селект лимит 100500) лимит 1.

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

ты так ни разу и не сформулировал целиком, что ты хочешь получить, сразу лепишь селекты...

Формулировал. Даже в первом посте выкладывал описание:

ты хоть раз объяснил, зачем тебе лимит во внутреннем запросе? зачем там вообще внутренний запрос?

Только там в правильный запрос. Без внутреннего селекта у меня это дело во временную таблицу не помещается, и мускуль это всё на диск кидает. А ждать концы такого запроса не имеет смысла.

В той же теме и писал зачем мне внутренний запрос

вот это? SELECT    A,    COUNT(*) AS Cnt FROM    (SELECT        A    FROM        tbl    WHERE        owner_id IN (SELECT DISTINCT owner_id FROM tbl WHERE A=:A)    ) a   GROUP BY    A ORDER BY    Cnt DESC LIMIT 10

Да, это самый главный запрос. До чего я дошёл - прикрутить хеш-множество в ущерб точности и скорости добавления/удаления. Но пока не сдаюсь)

а почему не так? SELECT   A,   COUNT(*) AS Cnt FROM   tbl WHERE   owner_id IN (SELECT DISTINCT owner_id FROM tbl WHERE A=:A) GROUP BY   A ORDER BY   Cnt DESC LIMIT 10

Внутренний запрос нужен был для LIMIT. В его забыл. А LIMIT нужен потому, что запрос выполняется больше 10 минут

а EXPLAIN что выводит?

А что он может нового вывести? Таблица на 16 млн строк. Ясен пень, что в оперативки не поместится для группировке, приходится на диск депить. Отсюда и время

для группировки*

лепить*

16мегастрок после фильтрации по овнерид?

Ошибся. Меньше конечно. Но в оперативку уже не влезает

прям не влезает? а какой тип у A?

если у обоих int то это примерно 8 байт на строку

Да.. Наврал получается.

это от ?

т.е. победа?

еще от derived избавится, заменив все на джоин можно попробовать

Да, но только через джоин. Не сказал бы, что 20 секунд это победа - дальше база расти будет

так тип-то какой?

и текст запроса

я вот не пойму, ты стесняешься, или думаешь, что твой запрос без данных кому-то нужен?

Int [1c]SELECT    a.artist_id,    a.title_id,    count(*) count FROM    audio a JOIN    (SELECT DISTINCT        owner_id    FROM        audio    ".$whereClause.") owners    ON owners.owner_id = a.owner_id GROUP BY    a.artist_id,    a.title_id LIMIT 100; [/1c]b Where artist_id = 234

+order by count

SELECT   a.artist_id,   a.title_id,   count(*) count FROM   audio a INNER JOIN audio b owners   ON owners.owner_id = a.owner_id    AND owners.artist_id = 234 GROUP BY   a.artist_id,   a.title_id

INNER JOIN audio owners

кстати, так хорошо все было через PDO, а тут вдруг рваный запрос...

Джоин с той же таблицей? Эквиваленто условию WHERE a.artist_id = 234

Запрос выдаёт не то

ты проверил?

Да В смысле "рваный запрос"? Я на yii пишу. Там удобно выполнять его

Извиняюсь. Забыл id на более популярный сменить. Про тоже был не прав)

рваный в том смысле, что клеится из кусочков, вместо использования PDO:PreparedStatement как в в сообщении Это заставляет много думать про фильтрацию входных данных, т.е. тех кусочков, из которых сам запрос клеится. ну так что, получше стало?

а сколько всего колонок в таблице?

попробуй поменяй count(*) на sum

В yii тоже можно собирать запрос. Но т.к. у меня запросы примитивные, я даже не стал вдаваться в подробности. Лучше особо не стало, разве только explain получше стал. Да и запрос) Возьму себе) Спасибо) Колонок 6, все инты

Те же 90 секунд.. Это он копируует во временную таблицу для группировки?

И всё-таки оказался косячным. Там не учитывается условие DISTINCT owners_id, и строки задваиваются

интересно, что кажут SHOW COLUMNS FROM audio и SHOW INDEX FROM audio

ишшо надо статистику пару раз обновить - analyze table

Field        Type    Null    Key    Default    Extra id        int    NO    PRI    NULL    auto_increment artist_id    int    NO    MUL    NULL     title_id    int    NO    MUL    NULL     aid        int    NO        NULL     owner_id    int    NO    MUL    NULL     duration    int    NO        NULL     Table    Non_uni    Key_name    Seq_in_index    Column_name    Collation    Cardinality    Sub_part    Packed    Null    Index_type    Comment    Index_comment audio    0    PRIMARY        1        id        A        15952265    NULL        NULL        BTREE         audio    1    art_tit_index    1        artist_id    A        1227097    NULL    NULL        BTREE         audio    1    art_tit_index    2        title_id    A        3988066    NULL    NULL        BTREE         audio    1    title_id    1        title_id    A        2658710    NULL    NULL        BTREE         audio    1    owner_id    1        owner_id    A        60886    NULL    NULL        BTREE

Field    Type    Null    Key    Default    Extra id    int    NO    PRI    NULL    auto_increment artist_id    int    NO    MUL    NULL     title_id    int    NO    MUL    NULL     aid    int    NO        NULL     owner_id    int    NO    MUL    NULL     duration    int    NO        NULL     ANALYZE TABLE audio = Table is already up to date Спасибо за участие!) Пока решил резать число владельцев - получается вполне сносно. Дальше буду ещё думать)

сделай 1 индекс на 2 поля: ownerId и artistId

Попробовал. Время не изменилось

А по artistId отдельно?