Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
Социальная инженерия и социальные хакеры. Авторы: Кузнецов М.В., Симдянов И.В. PHP на примерах (2 издание). Авторы: Кузнецов М.В., Симдянов И.В. Самоучитель PHP 5 / 6 (3 издание). Авторы: Кузнецов М.В., Симдянов И.В. Самоучитель MySQL 5. Авторы: Кузнецов М.В., Симдянов И.В. PHP 5/6. В подлиннике. Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Форум MySQL

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум (новые сообщения вниз) Структурный форум

тема: Миллионы пустых строк

Сообщения:  [1-10]   [11-12] 

 
 автор: Владимир55   (04.03.2009 в 12:21)   письмо автору
 
   для: serjinio   (04.03.2009 в 08:10)
 

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

   
 
 автор: serjinio   (04.03.2009 в 08:10)   письмо автору
 
   для: Trianon   (04.03.2009 в 06:16)
 

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

   
 
 автор: Trianon   (04.03.2009 в 06:16)   письмо автору
 
   для: serjinio   (04.03.2009 в 00:57)
 

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

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

   
 
 автор: serjinio   (04.03.2009 в 00:57)   письмо автору
 
   для: Владимир55   (02.03.2009 в 13:59)
 

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

$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);
 

   
 
 автор: Trianon   (02.03.2009 в 14:06)   письмо автору
 
   для: Владимир55   (02.03.2009 в 13:59)
 

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

   
 
 автор: Владимир55   (02.03.2009 в 13:59)   письмо автору
 
   для: Владимир55   (02.03.2009 в 12:34)
 

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

Так?

   
 
 автор: Владимир55   (02.03.2009 в 12:34)   письмо автору
 
   для: Trianon   (02.03.2009 в 12:30)
 

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

   
 
 автор: Trianon   (02.03.2009 в 12:30)   письмо автору
 
   для: Владимир55   (02.03.2009 в 12:23)
 

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

   
 
 автор: cheops   (02.03.2009 в 12:29)   письмо автору
 
   для: Владимир55   (02.03.2009 в 12:23)
 

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

   
 
 автор: Владимир55   (02.03.2009 в 12:23)   письмо автору
 
   для: Trianon   (02.03.2009 в 11:52)
 

Под пустыми строками я имел в виду вот что:
id     time_mks     time     new     ip     str_vh     kniga 
519416                        
519417                        
519418                        
519419                        
519420                        
519421

   

Сообщения:  [1-10]   [11-12] 

Форум разработан IT-студией SoftTime
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования