powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Нужен совет от гуру
32 сообщений из 32, показаны все 2 страниц
Нужен совет от гуру
    #38362135
Фотография paha4444
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Наполнил таблицу и в ней 2500 записей.
Теперь когда пытаю чтото выбрать чувствуюется реально задержка по времени. Так это всего 2500 записей, а если будет 10000 к примеру, что нужно будет ждать по несколько минут.

Сайт на джумле и вот мой запрос на выборку

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
  SELECT ads.id,
             ads.street,
             
             left(ads.text_ads, 180) as text_ads,
             ads.price,
             ads.currency,
             ads.ad_type,
             ads.type_of_housing,
             ads.type_of_host,
             ads.date_of_change,
             ads.alias as alias, 
             country.name as country_name,
             region.name as region_name,
             rayon.name as rayon_name,
             m_r.name as m_r_name,
             i_ads.thumbs as image_path
  
      FROM ads AS ads   

      LEFT JOIN image_ads AS i_ads ON i_ads.id_ads = ads.id AND main_image = 1 
      LEFT JOIN micro_rayon AS m_r ON m_r.id = ads.id_micro_rayon
      LEFT JOIN rayon ON rayon.id = ads.id_rayon
      LEFT JOIN region ON region.id = ads.id_region
      LEFT JOIN country ON country.id = ads.id_country      
            
  
   GROUP BY ads.id LIMIT 100,10; 



Здесь я выбираю 10 записей, начиная с 100, это своего рода пагинация.

Прошу совета, правильно ли составлен запрос, может я чтото не так выбираю. И если неправильно поправьте пожалуйста. Всем спасибо!
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38362153
tanglir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
paha4444,

во-первых, за такое
Код: plsql
1.
2.
3.
4.
5.
6.
 SELECT ads.id,
куча_полей_не_под_агрегатными_функциями
  
      FROM 
...
   GROUP BY ads.id LIMIT 100,10; 

надо сразу отправлять изучать основы скл.

Во-вторых, что показывает explain запроса?
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38362201
Фотография paha4444
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SELECT ads.id,
куча_полей_не_под_агрегатными_функциями

Как это понять?, этот способ выборки мне советовали тоже на форуме. Основы я изучал.

Вот что показал EXPLAIN


Напишите пожалуйста пример, как мне выбирать данные.

Спасибо.
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38362206
qwerty112
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
paha4444SELECT ads.id,
куча_полей_не_под_агрегатными_функциями

Как это понять?, этот способ выборки мне советовали тоже на форуме. Основы я изучал.

хрена хто такое советовал ! акстись ! - 14684048
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38362207
tanglir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
paha4444этот способ выборки мне советовали тоже на форумеНе всему можно верить. Ну или вы вообще исходный совет неправильно поняли.
paha4444Основы я изучал.Отлично, тогда вам не составит труда показать результат работы вот такого запроса
Код: sql
1.
select a,b from thetable group by a

на таких данныхab122324, а также объяснить, почему он получается именно таким. А лучше всего - включите only_full_group_by и медитируйте над выдаваемой ошибкой до просветления :)

А касательно эксплейна (отдельное спасибо за рисунок, к тому же неподгружающийся, вместо текста) - таблица image_ads цепляется без индекса, отсюда и тормоза. Индекс в ней на id_ads есть?
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38362211
Cygapb-007
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пожалуйста, обломайте мне руки вот за такое:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
select * 
from (
  select c.id, c.city, t.t_id, t.notes
  from city c
  left join comments t on t.c_id=c.id
  order by c.id,t.t_id desc
  )c_t
group by id;

Оно почему-то (хз почему, но - ) работает

Я понимаю, что берется первый элемент группы, но - группа предварительно явно отсортирована, а оптимизатору будет лениво (ятд) использовать какой-то другой порядок выборки - так что вроде бы всегда будет правильно? И никаких MAX не надо?

То есть это аналог действий оптимизатора по нахождению MAX, но как бонус - сразу извлекающий всю строку?

Или я чего-то не понимаю?
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38362214
Cygapb-007
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
забыл тестовые данные...
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
drop table if exists city;
CREATE TABLE `city` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `city` varchar(45) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
INSERT INTO `city` (`city`) VALUES ('city1'),('city2');

drop table if exists comments;
CREATE TABLE `comments` (
  `t_id` int(11) NOT NULL AUTO_INCREMENT,
  `c_id` int(11) DEFAULT NULL,
  `notes` varchar(45) DEFAULT NULL,
  PRIMARY KEY (`id`),
  CONSTRAINT `fk_comments_city` FOREIGN KEY (`c_id`) REFERENCES `city` (`t_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
INSERT INTO `comments` (`notes`, `c_id`) VALUES ('c11', '1'),('c12', '1'),('c13', '1');

...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38362233
Фотография paha4444
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tanglirpaha4444этот способ выборки мне советовали тоже на форумеНе всему можно верить. Ну или вы вообще исходный совет неправильно поняли.

Может быть.

paha4444Основы я изучал.Отлично, тогда вам не составит труда показать результат работы вот такого запроса
Код: sql
1.
select a,b from thetable group by a

на таких данныхab122324,

Выбрать поле a,b из таблицы thetable группировать по полю a


а также объяснить, почему он получается именно таким. А лучше всего - включите only_full_group_by и медитируйте над выдаваемой ошибкой до просветления :)

А касательно эксплейна (отдельное спасибо за рисунок, к тому же неподгружающийся, вместо текста) - таблица image_ads цепляется без индекса, отсюда и тормоза. Индекс в ней на id_ads есть?

Я нажал тут на вставить изображение, вроде бы тег добавился, вобщем вот рисунок
http://pixs.ru/showimage/2013081110_1280431_8712247.png

image_ads цепляется без индекса, отсюда и тормоза. Индекс в ней на id_ads есть?
нет, индекса нет, сейчас попробую добавить индекс.
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38362235
Фотография paha4444
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Добавил индекс сейчас все круто!!!! Спасибо огромное!!!
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38362238
Фотография paha4444
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
paha4444Добавил индекс сейчас все круто!!!! Спасибо огромное!!!

Еще вопрос. А можно добавить индекс каждой таблице, где привязка по ID? Это будет без болезненно и производительно?
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38362371
Фотография javajdbc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
paha4444paha4444Добавил индекс сейчас все круто!!!! Спасибо огромное!!!

Еще вопрос. А можно добавить индекс каждой таблице, где привязка по ID? Это будет без болезненно и производительно?

В обшем виде -- нужный индекс дает большие преимушества.
Ненужный индекс имеет небольшое отрицательное влияние.

Индекс, обычно, нужен во всех местах где идет связка
по ФК-ПК -- в частности "привязка по ИД" как вы сказали.
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38362397
Фотография paha4444
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вот смотрите.

У меня идут таблицы:

Объявления

Изображения к ним(пути к файлам)

Страна

Регионы

Области

Тут везде идет привязка по ID.
В таблице с объявлениями в некоторых полях у меня храняться ID из других таблиц.
Сейчас у меня индекс есть в таблице с Изображениями в поле id_ads(id объявления)

Я вот думаю может добавить индекс в каждую табличку и в табличку с объявлениями на поле id
Как считаете?

Но сейчас работает все молнейносно, токо отправляеться запрос сразу же получаю ответ. Круто!!!
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38362470
Фотография javajdbc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
paha4444,

одна из мантр баз данных -- надо индекс на каждую связку.
Однако если все работает достаточно для вас быстро --
полезнее занятся следуюший задачей....(или пивом учитывая выходные).
и вернутся к оптимизации когда что-то будет работать медлено.
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38362564
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cygapb-007Или я чего-то не понимаю?Именно.
Есть стандарт. Написанное тобой по нему - ересь.
Есть реализованные в конкретном языке расширения и отступления от стандарта. Они либо документированы либо нет. Твой случай - это когда НЕ документированы. Значит, то, что у тебя получается ожидаемый тобой результат - негарантировано, обычная случайность.
Повод обломать руки - есть... подставляй.
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38362717
Cygapb-007
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AkinaCygapb-007Или я чего-то не понимаю?Именно.
Есть стандарт. Написанное тобой по нему - ересь.
Есть реализованные в конкретном языке расширения и отступления от стандарта. Они либо документированы либо нет. Твой случай - это когда НЕ документированы. Значит, то, что у тебя получается ожидаемый тобой результат - негарантировано, обычная случайность.
Повод обломать руки - есть... подставляй.Именно:)
Про стандарт я в курсе, однако в MS SQL до сих пор без проблем работает "хитрый" update table @var+=field (который нигде не документирован) - может и здесь та же фигня?

Пока не опроверг - рук не подставлю
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38362729
Cygapb-007
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[quot Akina]Cygapb-007Значит, то, что у тебя получается ожидаемый тобой результат - негарантировано, обычная случайность. .Уточняю - жду пример, когда результат отличается от ожидаемого :)
Или описания ситуации, когда MySQL пересортирует вложенный (и уже явным образом отсортированный) запрос при построении группировки по полю.

А кивать на общий стандарт SQL применительно к конкретному языку - по-моему, не совсем корректно (тот же MS SQL просто выдаст синтаксическую ошибку, да и MySQL тоже, если включить ONLY_FULL_GROUP_BY )

PS. Например, для MS SQL - был приведен запрос, когда select * from MyTable выдавал записи в произвольном (каждый раз разном) порядке даже при наличии кластерного первичного ключа :)
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38362742
Cygapb-007
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И еще одно возражение...AkinaТвой случай - это когда НЕ документированы.А как же 12.15.3. MySQL Extensions to GROUP BY ??
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38362855
Cygapb-007
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Так все же, резюмируя, - можно пользоваться таким ( 14693070 ) приемом при поиске последнего комментария,
или возможны ситуации (например, с распараллеливанием выполнения запроса), когда по GROUP BY будет выбрано не максимальное для группы значение?
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38362909
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cygapb-007,

У вас там "косяк" в том, что предварительную сортировку в подзапросе Вы делаете по DESC, а группировка в Мускуле "по умолчанию", и внезапно - делает ASC. Соответственно, думаю можно подобрать ТАКИЕ наборы данных, для которых внутренняя предварительная группировка 0 неэффективна и послоедующий групбай - перевесит вашу явную сортировку напрочь.

Так что, даже если "в целом" запрос "практически" работает - за такое, я бы ручки точно от разработки реальных проектов отлучил "не задумываясь", но... не переживайте. Здесь таких "гуру" - каждый третий.
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38362915
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tanglir,

нет там особых проблем с "неподагрегатными" функциями. В отличие от предыдущего "автора", тут идет явное разворачивание данных по одной базовой таблице и записи множиться явно - не намерены. Можно и без агрегатов в таком случае... но, если оно действительно так - то есть автор способен гарантировать единичность выборок левых джойнов.

... а про индексы - тут уже прошлись и без меня.
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38362933
Cygapb-007
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arhat109Cygapb-007,

У вас там "косяк" в том, что предварительную сортировку в подзапросе Вы делаете по DESC, а группировка в Мускуле "по умолчанию", и внезапно - делает ASC. Соответственно, думаю можно подобрать ТАКИЕ наборы данных, для которых внутренняя предварительная группировка 0 неэффективна и последующий групбай - перевесит вашу явную сортировку напрочь.

Так что, даже если "в целом" запрос "практически" работает - за такое, я бы ручки точно от разработки реальных проектов отлучил "не задумываясь", но... не переживайте. Здесь таких "гуру" - каждый третий.Хохма в том, что серверу не нужно сортировать по id_message , достаточно отсортировать по id_user . То есть на вход сортировки поступает последовательность записей, сортировщик начинает сортировать ее по полю id_user - но по этому полю последовательность уже отсортирована, поэтому никаких дополнительных перемещений записей во входном наборе вроде бы не ожидается (иначе это увеличило бы стоимость плана выполнения)...
Да, я согласен с тем, что http://dev.mysql.com/doc/refman/5.5/en/group-by-extensions.html You can use this feature to get better performance by avoiding unnecessary column sorting and grouping. However, this is useful primarily when all values in each nonaggregated column not named in the GROUP BY are the same for each group . The server is free to choose any value from each group , so unless they are the same, the values chosen are indeterminate.но не вижу причин, побудивших бы его реально выполнить пересортировку поступающих данных.
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38362946
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cygapb-007,

Вся "хохма" в том, что вы так и не поняли, что выборка значений без агрегатов происходит ДО этапа сортировки и группировки. Это раз. И второе то, что этап группировки у Мускуля - производит сортировку "на лету"... что в сочетании с "произвольностью выборки" сервером - приводит к практически гарантированно неопределенному выполнению запроса.

Обычно, именно за это - ручки и обрывают. Не от вашего "бренного тельца"... от проектов конечно же...
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38362973
Cygapb-007
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arhat109Cygapb-007,

Вся "хохма" в том, что вы так и не поняли, что выборка значений без агрегатов происходит ДО этапа сортировки и группировки. Это раз. И второе то, что этап группировки у Мускуля - производит сортировку "на лету"... что в сочетании с "произвольностью выборки" сервером - приводит к практически гарантированно неопределенному выполнению запроса.

Обычно, именно за это - ручки и обрывают. Не от вашего "бренного тельца"... от проектов конечно же...Вы хотите сказать, что в результате выполнения практически гарантированно получатся неверные результаты?? Ситуация прямо противоположная - практически (не теоретически!) гарантированно результаты будут ожидаемыми !

Я как раз хочу понять, в каких ситуациях в принципе возможны неверные результаты (а не кричать "аллилуйя" и "ересь")

Я согласен, что сервер вправе самостоятельно выбрать, данные из какой конкретной строки группы выбрать в качестве результата, но не вижу причин "утяжелять" план выполнения и брать их не из первой же строки группы
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38362994
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cygapb-007,

У вас верные результаты, только благодаря тому что порядок следования записей в таблице совпадает с указанными сортировками. "Так получилось". По удаляете и повставляйте записи "туда-сюда" в случайном порядке нумерации и поедет ваш результат "к бабушке".

Оттого что вы указали первую сортировку ASC, а вторую DESC - нисколько её не отменяет. Отменить её может только отсутствие записей с одинаковым первым ключом... и только. Как только появятся записи в сортировке DESC, и как только они будут реально лежать в порядке ASC в файле таблички - пойдёт оно всё лесом... Вы никак понять не можете, что выбор из какой записи реально взять не агрегированное поле - действительно всегда будет "из первой попавшейся"... и вот когда "первой попавшейся" (в файле таблички) окажется "не та запись", ваш запрос рухнет, и никому ничего даже не вякнет... больше того, далеко не всегда "потом" удается заставить такое работать, даже прибивая "нужные индексы" гвоздями... то есть, по сути, вы сознательно оставляете после себя минное поле, на котором ваш код будет скользить и хорошо, если у вас а не у того кто придёт после... собственно, не принимайте "близко к сердцу"... теперь это нормальный способ сделать себя "незаменимым". Я уже это вижу достаточно часто.
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38362995
tanglir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arhat109Можно и без агрегатов в таком случае... но, если оно действительно так - то есть автор сопсобен гарантировать единичность выборок левых джойнов.Загвоздка в том, что автор об этом не знал (ну... я уверен, что он об этом не знал :)). Т.е. гарантировать-то, наверное, мог, и так делать в этом конкретном случае действительно было бы можно, но он же ж потом стал бы такое и дальше лепить, пока рано или поздно на эти грабли бы не наступил. Так что я решил его заранее предупредить :)
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38363004
Cygapb-007
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arhat109,

насколько я понял Ваше возражение, оптимизатор в процессе построения оптимального плана выполнения может просто проигнорировать сортировку итогов вложенного запроса? Не уверен, что он вправе проводить такую "оптимизацию"...
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38363021
Cygapb-007
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хотя, с другой стороны...
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
select * 
from (
  select c.id, c.city, t.t_id, t.notes
  from city c
  left join comments t on t.c_id=c.id
  order by c.id,t.t_id desc
  )c_t
group by id;


Чтобы предотвратить материализацию итогов вложенного запроса во временную таблицу, возможно, оптимизатор и проигнорирует внутреннюю сортировку... И тогда действительно будут получены неверные данные...
Только неясно тогда, почему MySQL допускает ее (внутреннюю сортировку) синтаксически...
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38363141
tanglir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cygapb-007Не уверен, что он вправе проводить такую "оптимизацию"...Тут подходить надо с другой стороны. Ему не запрещено её проводить, т.к. порядок внутренней сортировки никак не должен влиять на порядок сортировки итога.
Cygapb-007Только неясно тогда, почему MySQL допускает ее (внутреннюю сортировку) синтаксически...Ну он и check constraints допускает при создании таблицы, а на самом деле ими там и не пахло
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38363190
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cygapb-007оптимизатор в процессе построения оптимального плана выполнения может просто проигнорировать сортировку итогов вложенного запроса? Не уверен, что он вправе проводить такую "оптимизацию"...Смутно припоминаю, что видел в доке упоминание, что вправе. К сожалению, найти сейчас не могу.
Однако, нашел вот это:
MySQL 5.6 subquery ORDER BY behaviour changed from 5.5
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38363194
Cygapb-007
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В общем, ONLY_FULL_GROUP_BY должно быть всегда включено , потому что никакой оптимизацией тут и не пахнет, зато прямо-таки воняет причиной неявных ошибок в коде
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38363196
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cygapb-007,

Проблема в том, что внутренним подзапросом вы получаете некий промежуточный набор, даже отсортированный "как надо". Но, на внешнем уровне у вас стоит только группировка без агрегирования. И, как раз, в случае отсутствия выкладки во временную табличку, при сборке выхода, остальные части неагрегированной выдачи, Мускуль вправе взять "первые попавшиеся"... не из внутренней таблички подзапроса, а ваще первые попавшиеся. Вы ему ЭТО РАЗРЕШИЛИ.
...
Рейтинг: 0 / 0
Нужен совет от гуру
    #38363210
Cygapb-007
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoftCygapb-007оптимизатор в процессе построения оптимального плана выполнения может просто проигнорировать сортировку итогов вложенного запроса? Не уверен, что он вправе проводить такую "оптимизацию"...Смутно припоминаю, что видел в доке упоминание, что вправе. К сожалению, найти сейчас не могу.
Однако, нашел вот это:
MySQL 5.6 subquery ORDER BY behaviour changed from 5.5 Спасибо, ссылка "в жилу". Повторимость результата, к сожалению, не гарантирует, но зато прекрасно демонстрирует своеволие сервера (как и было обещано в документации) по выбору включаемой в итог строки из группы .
...
Рейтинг: 0 / 0
32 сообщений из 32, показаны все 2 страниц
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Нужен совет от гуру
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]