Форум MySQL

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

Чтобы этого избежать, в конце каждого дня за пять минут до полуночи по команде Cron извлекается вся нужная информация из оперативной таблицы и обрабатывается как это требуется, а результаты обработки помещаются в архивные таблицы для использования администратором. В оперативной таблице остаются лишь результаты сегодняшнего дня для завтрашней обрабоки (это нужно), а остальное идет под DELETE.
Таким образом, объем оперативной таблицы практически не растет, хотя число строк продолжает увеличиваться.

Простая прикидка показала, что через год картина будет такая: двадцать-тридцать миллионов пустых строк, после которых есть информационный массив примерно на сто тысяч строк, и к этому массиву происходит обращение запросами INSERT INTO, SELECT, UPDATE и др. Но ведь эти операторы обрабатывают таблицу вцелом! А если так, то всё равно будут тормоза.

Верно?


Этот вариант уже вопощен, и, хотя пока что тормозов я не ощущаю, всё же возникают сомнения в его оптимальности.

Другой вариант - ежедневнй TRUNCATE оперативной таблицы в нетранзакционном режиме и занесение из буфера в эту же полностью очищенную таблицу массива, необходимого для продолжения работы. Тогда пустых строк не будет.

Понятно, что TRUNCATE может внести ошибки в накапливаемую информацию, но нюанс в том, что данные за последние пять минут всё равно исключаются из обработки (да и что там случится за эти минуты!).

Вот я и думаю: есть ли необходимость в переделке? Или пустые строки, хоть их и миллионы, не замедляют работу базы?

что Вы называете пустыми строками?
Строка удаленная ( DELETE) в таблице не хранится.

Под пустыми строками я имел в виду вот что:

id     time_mks     time     new     ip     str_vh     kniga  519416                         519417                         519418                         519419                         519420                         519421

Все-равно не понятно, если вы прошлись DELETE-ом строки нет... или у вас как-то образуются строки в которых просто все поля имеют значение либо 0, либо NULL, либо ""?

ну это строки непустые.
DELETE к ним не применялось.
Они действительно занимают место в таблице и в индексе первичного ключа.

Коли так, то надобно мне взглянуть ещё раз под этим углом зрения...

Да, я ошибался - строки, обработанные DELETE, уже не выводятся, хотя их id остаются занятыми. То есть, за счет наращивания количества удаленных строк база не растет. Будь их хоть триллион. И быстродействие от большого числа удаленных строк не снижается.

Так?

есть такой запрос OPTIMIZE TABLE, который перераспределяет пространство табличного файла и причесывает индексы. Рекомендуется периодически его исполнять. Раз в месяц, к примеру.
На последовательность первичных ключей он влияния не оказывает, само собой.
предел INT - два миллиарда с небольшим.

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

$rw_n = mysql_fetch_assoc(mysql_query("SHOW TABLE STATUS LIKE 'temp'",$db)); if ($rw_n['Data_free'] > 100) mysql_query("OPTIMIZE TABLE `temp` ",$db); mysql_close($db);

из-за каждой паршивой сотни байт оптимизацию проводить не стоит...

[поправлено модератором]

нет конечно ,100,это чтоб наглядней было...

Если в конце дня делается какая-то операция по Cron, то, как я полагаю, заодно можно осуществлять и упорядочение базы. Так?