имам една таблица, в която се записва историята на сайта - тоест всяко кликане...
за седмица там се трупат малко над половин милион записа...

трия ги с една заявка
DELETE FROM history WHERE last_time < DATE_ADD( now( ) , INTERVAL -7 DAY )

та наскоро забелязах, че сайта се бави...ама много
и с ужас видях, че десетина такива заявки стоят в процесите на MySQL-а локнати....

заявката се изпълняваше при всяко отваряне на страница, и се трият по няколко записа...

та какво направих - заявката вече се изпълнява веднъж на денонощие...
но когато я пуснах на ръка, за да изтрия записите за последните 2 дни заявката се изпълни за 120 секунди...

това ми се вижда много...

та за това въпроса ми е има ли начин да се ускори тази заявка...
и въобще бъркам ли някъде и ако да - какво ?

Съдържаниет е скрито
Влезте за да го видите

и естествено питай EXPLAIN

EXPLAIN SELECT last_time FROM history
WHERE last_time < NIOW( ) , - INTERVAL 7 DAY;

На мен този синткатсис на DATE_SUB() ми е много по разбираем

Съдържаниет е скрито
Влезте за да го видите

1. Ползваш ли записаните неща? Щото ако никой за нищо не ги ползва най-лесния начин за триенето им е като не се записват.

По принцип ако не се лъжа както си написал заявката на всеки ред се изчислява
DATE_ADD( now( ) , INTERVAL -7 DAY )
Не съм сигурен де ама имам някакви смътни спомени. Та вероятно ако използваш директно изчислен израз може би ще се ускори много.
Последното което ми хрумва:
1. С обикновен селект намираш ИД на първия от записите за триене.
2. След това триеш всички с ИД по малко от намереното.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

"По принцип ако не се лъжа както си написал заявката на всеки ред се изчислява DATE_ADD( now( ) , INTERVAL -7 DAY ) "

Грешиш този израз се изчислява само веднъж.

Съдържаниет е скрито
Влезте за да го видите

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

Имаше подобен въпрос преди време (ама подобен), та си спомням че ти там обясняваше че става изчисляване на всеки ред - за това се подведох де.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

зависи от коя страна на равенството изчисляваш

... WHERE col = 1 + 2; -> изразът 1+ 2 се изчислява еднократно и при изпълнение зявката придобива вид
col = <константа>

... WHERE col - 1 = 2; -> тук изразът (col - 1) трябва да се изчисли за всяка стойност на col т.е. за всеки ред и оттам индексите не вършат работа

Съдържаниет е скрито
Влезте за да го видите

И още нещо ми се мотае из главата .....
при толкова много insert/delete
колко ли се фрагментира таблицата на файлово ниво ?

след такава голяма операция пускай чат-пат
optimize table ......

root@ro6avia#echo rm -rf * > /bin/seek_and_destroy
root@ro6avia#/bin/seek_and_destroy

ползвам ги, разбира се... най-малкото за да се хваля на приятели ;-)

та каква е разликата дали ще трие всичко от дата по-малка от намерената или от ID по-малко от намереното...

Съдържаниет е скрито
Влезте за да го видите

че това как ще напиша DATE_ADD има някакво значение за бързодействието...все пак смята се един път само :-)

а ето какво връща EXPLAIN-а:

EXPLAIN SELECT last_time FROM history WHERE last_time < DATE_ADD( now( ) , INTERVAL -7 DAY ) ;



table	type	possible_keys	key 	 	key_len  	ref 	 rows  	Extra

history 	range 	last_time_idx 	last_time_idx 	8 	NULL 	15595 Using where; Using index

Съдържаниет е скрито
Влезте за да го видите

Ами индекса ти е един INT - и сравненията са по бързи във всички случаи.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите