UPDATE нескольких строк.

[vedro-compota]

просто чтобы хотя бы отфетчить все 1053 записи серваку потребуется побольше времени

на экран вывелось только 30) - там limit в phpmyadmin)
-----------------------------------

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

пробую.

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

 SUM(EXAM_MARKS.MARK)>33

- всего 6 строк.
структура бд такая -

create table SUBJECT
(
  SUBJ_ID   NUMERIC not null,
  SUBJ_NAME VARCHAR(100),
  HOUR      NUMERIC,
  SEMESTER   NUMERIC
);
alter table SUBJECT
  add primary key (SUBJ_ID);
create table UNIVERSITY
(
  UNIV_ID   NUMERIC not null,
  UNIV_NAME VARCHAR(160),
  RATING    NUMERIC,
  CITY      VARCHAR(60)
);
alter table UNIVERSITY
  add primary key (UNIV_ID);
create table LECTURER
(
  LECTURER_ID NUMERIC not null,
  SURNAME     VARCHAR(60),
  NAME        VARCHAR(60),
  CITY        VARCHAR(60),
  UNIV_ID     NUMERIC
);
alter table LECTURER
  add primary key (LECTURER_ID);
alter table LECTURER
  add constraint UNIVLECT_FOR_KEY foreign key (UNIV_ID)
  references UNIVERSITY (UNIV_ID);
create table STUDENT
(
  STUDENT_ID NUMERIC not null,
  SURNAME    VARCHAR(60),
  NAME       VARCHAR(60),
  STIPEND    NUMERIC(16,2),
  KURS       NUMERIC,
  CITY       VARCHAR(60),
  BIRTHDAY   DATE,
  UNIV_ID    NUMERIC
);
alter table STUDENT
  add primary key (STUDENT_ID);
alter table STUDENT
  add constraint UNIV_FOR_KEY foreign key (UNIV_ID)
  references UNIVERSITY (UNIV_ID);
create table EXAM_MARKS
(
  EXAM_ID    NUMERIC not null,
  STUDENT_ID NUMERIC not null,
  SUBJ_ID    NUMERIC not null,
  MARK       NUMERIC,
  EXAM_DATE  DATE
);
alter table EXAM_MARKS
  add primary key (EXAM_ID,STUDENT_ID,SUBJ_ID);
alter table EXAM_MARKS
  add constraint STUDENT_FOR_KEY foreign key (STUDENT_ID)
  references STUDENT (STUDENT_ID);
alter table EXAM_MARKS
  add constraint SUBJECT_FOR_KEY foreign key (SUBJ_ID)
  references SUBJECT (SUBJ_ID);
create index STUDENT_ID_1 on EXAM_MARKS (STUDENT_ID);
create table SUBJ_LECT
(
  LECTURER_ID NUMERIC not null,
  SUBJ_ID     NUMERIC not null
);
alter table SUBJ_LECT
  add primary key (LECTURER_ID,SUBJ_ID);
alter table SUBJ_LECT
  add constraint LECT_FOR_KEY foreign key (LECTURER_ID)
  references LECTURER (LECTURER_ID);
alter table SUBJ_LECT
  add constraint SUBJ_FOR_KEY foreign key (SUBJ_ID)
  references SUBJECT (SUBJ_ID);

[Serge_Bliznykov]

да, является - primary key.

ну вот, я случайно не то ляпнул, а Вы подтвердили!..

Вы ТОЧНО уверены, что в таблице оценки (EXAM_MARKS) поле STUDENT_ID является первичным ключом?! Этого НЕ МОЖЕТ БЫТЬ! Тогда бы Вы не смогли добавить больше одного экзамена по одному студенту!Проверьте и обязательно добавьте индекс по полю STUDENT_ID в таблице EXAM_MARKS


добавлено
угу. увидел. вижу теперь, есть у Вас такой индекс:

create index STUDENT_ID_1 on EXAM_MARKS (STUDENT_ID);

но, если не поможет, я тогда не знаю, в чём причина..
на таблице STUDENT нет никаких триггеров?
Вот сколько выполняется запрос по обновлению ВСЕ записей?
например такой:

UPDATE STUDENT set STIPEND = STIPEND *1.2;

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

[vedro-compota]

если так

UPDATE STUDENT set STIPEND = STIPEND *1.2;

, то -

Затронуто строк: 5365 (запрос занял 0.2081 сек.)

------------------

ну вот, я случайно не то ляпнул, а Вы подтвердили!..

да) отличился я)
насчёт триггеров не знаю - на практике с ними заданий не было - сам ещё не изучал)

да) база учебная) вообще подразумевалась для оркл, но я ещё отправил в mysql.
так как sql запросы , которые мы проходим, идентичны для обеих СУБД) ну или почти идентичны)

[Serge_Bliznykov]

Затронуто строк: 5365 (запрос занял 0.2081 сек.)

ну, судя по времени выполнения никаких триггеров (по крайнем мере, "тяжёлых") на таблице нет...

тогда.
1) попробуйте такой вариант:

UPDATE STUDENT set STIPEND = STIPEND *1.2
WHERE STUDENT_ID IN
(SELECT OTL.STUDENT_ID
  FROM (SELECT EXAM_MARKS.STUDENT_ID, SUM(EXAM_MARKS.MARK) as EX_SUM 
  FROM EXAM_MARKS
  GROUP BY EXAM_MARKS.STUDENT_ID) as OTL
  WHERE OTL.EX_SUM >20)

если время его выполнения окажется недопустимо большим,
тогда, лично я, вижу только один вариант - временная таблица (или курсор), куда запросом вытаскиваем нужные ID студентов, а потом, второй запрос - уже собственно update...

[soleil@mmc]

может кто-то залочил таблицу в какой-нить транзакции?

[vedro-compota]

1) попробуйте такой вариант:

Serge это работает!) -

Затронуто строк: 1051 (запрос занял 9.6803 сек.)

теперь осталось понять что не так в исходном запросе -

UPDATE STUDENT set  STIPEND = STIPEND *1.2 where STUDENT_ID IN 
( SELECT EXAM_MARKS.STUDENT_ID  FROM EXAM_MARKS  GROUP BY EXAM_MARKS.STUDENT_ID
 HAVING SUM(EXAM_MARKS.MARK)>20);

)))))
но самое главное что ваш вариант работает!)))
--------------------
soleil@mmc ,а как проверить эту ммм..заключённость?

[vedro-compota]

ага.....причина в HAVING.....это условие проверяется после получения массива строк....вроде как. где-то я сегодня про это прочитал...на сайте каком-то...

[Serge_Bliznykov]

ага.....причина в HAVING.....это условие проверяется после получения массива строк....

ну, не надо делать такие скоропалительные выводы..
вот, например, моего личного опыта не хватает, чтобы сделать однозначный вывод, почему с HAVING запрос работает на порядки медленнее... Думаю, что либо какой-то нюанс не учитывается, либо, банально, но это так часто бывает, это особенность движка базы (т.е. особенность самой БД). Ведь при построении запроса внутри БД решаются весьма сложные задачи... Теоретически нужно 1) штудировать документацию на текущую версию БД. 2) изучать (анализировать) план запроса.
Например, проверьте, если есть возможность, тот же самый запрос с HAVING но под Oracle как отработает? Не удивлюсь, если там будет работать быстро!

но самое главное что ваш вариант работает!)))

вот и славно! Поздравляю нас с Вами!

[vedro-compota]

Serge_Bliznykov, спасибо Вам)

Kлючевое слово HAVING работает следующим образом: сначала GROUP BY разбивает строки на группы, затем на полученные наборы накладываются условия HAVING.

отсюда

Предложение HAVING чаще всего используется после предложения GROUP BY в случаях, когда условие поиска должно проверяться уже после группировки результатов.

отсюда
---------------------------