Бавно..

Това нещо и преди ми се беше случвало, но сега реших да питам..
Имам една табличка(горе/долу такава)
|orderid|user|amount|
и решавам да видя кой user какъв amount е натрупал

SELECT user, SUM(amount)
FROM tbl
GROUP BY user

И това нещо върху < 2000 записа се изпълнява от порядъка на 20 мин.!!!!
В process-list-а на сървъра стои едно такова съобщение:"Copying to tmp table"
Ако ги извъртя сумата за всеки user
SELECT sum(amount) FROM tbl WHERE user = 'var';
всичко си е OK
Имате ли идея защо това се бави толкова много. Първоначално даже си мислех, че MySQL(3.23.41) забива. Пробвах го и на различни машини - навсякъде така се бави......

If you don't care where you are going any road will get you there

при < 2000 записа.....не трябва изобщо да се бави...
то за 20 мин. на ръка с молив ще ги сметна...

никога не съм имал високо мнение за MySql ама мисля, че не е в него причината....

виж как стои въпроса със свободното място по дисковете където са ти дейта файловете и там където се правят временните файлове
виж и паметта на компютъра да не е недостатъчно (макар, че лично аз не знам как да дефинирам достатъчно)

всъщност, нямам голям опит с MySql но си спомням един дълъг файл пълен с настройки...данеби там да има издънка?

2000 реда са нищо работа.

погледни пак какво казва SHOW PROCESSLIST;

Да не би да имаш друга сесия, която е заключила същата таблица?

Copying to tmp table e нормално а при такава заявка би трябвало да остане в паметта и да не пише по диска.

Дай малко повече информация.

salle.online.bg/sig

Ето един тест със случайни глупости натъпкани в таблица tbl (user, amount)

mysql> select count(*) from tbl;
+----------+
| count(*) |
+----------+
| 1750394 |
+----------+
1 row in set (0.00 sec)

mysql> SELECT user, SUM(amount)
-> FROM tbl
-> GROUP BY user;
+------+-------------+
| user | SUM(amount) |
+------+-------------+
| 118 | 459405869 |
| 137 | 460298583 |
| 231 | 459790461 |
| 242 | 460134932 |
| 302 | 462871127 |
| 354 | 460982849 |
| 401 | 459838072 |
| 435 | 459746111 |
| 479 | 460530635 |
| 499 | 461010938 |
| 531 | 459784649 |
| 540 | 460590823 |
| 564 | 459881078 |
| 748 | 460274923 |
| 80 | 461154447 |
| 868 | 461026343 |
| 913 | 459904102 |
| 919 | 460972789 |
| 985 | 460921309 |
+------+-------------+
19 rows in set (1 min 3.14 sec)

Вярно, че машината ми не е бавна, но пък редовете са 1.7 милиона

salle.online.bg/sig

"достатъчно" е като във стария виц с пионерчетата и влака - Колкото се може повече

Това за дългия файл пълен с настройки пък съвсем ме шашна вече.

Сега остава да кажеш, че Oracle има по-малко настройки ...


За паметта ... то си пише:

[линк]
[линк]
[линк]

salle.online.bg/sig

Това user име ли е или ID? - Трябва да е ID и според мен трябва да е индексирано полето.

Ако е ID и полето е индексирано - нямам идея.

Не се обиждай ако въпросите ти се струват тъпи

__________________________________
Пътят към ада е осеян с добри намерения

Оказа се проблем с паметта :-/, на 2те машини където го пробвах работи и един друг сървър с по-вискок приоритет, със доста гаден memory leak(~2GB за 2-3 дена). Първоначално теорията за паметта ме съмняваше - и 2те са с над 512MB, а и данните са смешно малко. Мерси.

If you don't care where you are going any road will get you there

профилирано ми е съзнанието.....
в повечто случай настройките по подразбиране, сякаш са оптимизирани за моя случай....
рядко се налага да се занимавам с памети и прочие...
иначе за "достатъчно" съм съгласен....

пише, прав си...стига да има кой да чете....

Това antipop откъде идва?
Да не е от Примус?

salle.online.bg/sig

да

If you don't care where you are going any road will get you there