mysql  100  000  000  строк,  есть  поле  time  разделяющее  таблицу  на  группы,  
выполняется  запрос  примерно:  delete  from  {table_name}  where  time<  curent_time-86400,   
 в  процессе  запрос  висит в потоке уже  более  8  часов,  
все  новые  запросы  к  таблице  тоже  зависают,  
как  снять  запрос  с  потока  не  нашел,  к  тому  же  есть  подозрение  что  в  таком  случае  все  наработки  анулинруются,  
что  делать,  ждать  дальше  завершения  или  предпринимать  какие  то  действия?
можете ли посоветовать что то для ускорения процесса удаления по условию в огромной таблице?(более 100  миллионов строк)

Это сообщение отредактировал(а) Nick007 - 4.6.2011, 18:30

И каковы структура и размер этой таблицы?

Что-то дофига... индекса по time нет, что ли?

Секционирование, наверное...

Секционирование это что?
в таблице 7 полей все числовые
в таблице несколько полей на каждом есть индекс.
размер таблицы щас глянуть не могу, запросы таблица не принимает вообще ни какие

Добавлено через 5 минут и 38 секунд
очередь запросов к таблице висит более 10 часов

Это сообщение отредактировал(а) Nick007 - 4.6.2011, 20:58

уже несколько раз наткнулся на партиции,
можете ли подсказать мне что это и можно ли с их помощью разбить таблицу по полю с датами?

Это сообщение отредактировал(а) Nick007 - 4.6.2011, 22:04

http://dev.mysql.com/doc/refman/5.5/en/mer...age-engine.html
Помогает при (по большей части идиотском) построении БД, когда выполняется деление сущности на таблицы по какому-то атрибуту. Но в твоём случае это может быть оправдано - секционирование по дате (например, помесячно).

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

действительно задача состоит в разбитии таблицы на части по времени,

Это сообщение отредактировал(а) Nick007 - 5.6.2011, 10:23

у меня есть 2 архивные таблицы,
в них переодически сбрасываются данные из буферной таблицы в порядке где то 180000 строк.

в первую каждый час во вторую раз в сутки,
при создании в первой 25го куска этих данных удаляется 1ый
во второй при создании 90го куска удаляеся 1ый.

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

щас появилась идея сделать секционирование по хешу,
что бы в каждую секцию попадали данные за определенный промежуток времени
и что бы удаление проходило быстрее

вот гадаю как это лучше реализовать.

а вы можете мне подсказать как можно динамически добавлять и удалять партиции?

Кто ни будь знает как остановить выполнение текущего запроса к базе?

SHOW FULL PROCESSLIST
KILL QUERY id_процесса

помогло уничтожить зависший процесс, 
результат:
за 14 часов из 144000000 строк уничтожено 10000000

Для этого лучше всего написАть хранимые процедуры, которые выполнят требуемые действия.

Первая - на удаление. Ей передаётся имя удаляемой таблицы либо "час Х". Если передано время - процедура предварительно получает из information_schema имена всех разделов, и запросами в каждый раздел по отдельности 


определяет, следует ли эту секцию удалять (удаляем, если первый запрос вернул ноль, а второй - ненулевое значение).
Получив имя удаляемой таблицы, динамически строим и выполняем (см. prepared statement) запрос на изменение секционированной таблицы, исключая удаляемую. При удаче - дропаем удаляемую таблицу.
Если удаление не прошло - выставляем соотв. сигнал.

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

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

пытаюсь создать таблицу следующим образом:

CREATE  TABLE  `test_partition`  (
     `id`  int(10)  unsigned  NOT  NULL  AUTO_INCREMENT,
     `time`  int(10)  unsigned  DEFAULT  '0',
     `id_te`  int(10)  unsigned  NOT  NULL  DEFAULT  '0',
     `region`  int(10)  unsigned  NOT  NULL  DEFAULT  '0',
     `battl`  int(10)  unsigned  NOT  NULL  DEFAULT  '0',
     `game`  int(10)  unsigned  NOT  NULL  DEFAULT  '0',
     `rpos_int`  int(11)  DEFAULT  '0',
     `rshift_int`  int(11)  DEFAULT  '0',
     `rshift_v`  int(11)  DEFAULT  '0',
     `realm`  int(10)  unsigned  NOT  NULL  DEFAULT  '0',
     `faction`  int(10)  unsigned  NOT  NULL  DEFAULT  '0',
     `wins`  int(10)  unsigned  NOT  NULL  DEFAULT  '0',
     `losses`  int(10)  unsigned  NOT  NULL  DEFAULT  '0',
     `rating`  int(10)  unsigned  NOT  NULL  DEFAULT  '0',
     PRIMARY  KEY  (`id`),
     KEY  `time`  (`time`),
     KEY  `id_te`  (`id_te`),
     KEY  `region`  (`region`),
     KEY  `battl`  (`battl`),
     KEY  `game`  (`game`),
     KEY  `rpos_int`  (`rpos_int`),
     KEY  `rshift_int`  (`rshift_int`),
     KEY  `rshift_v`  (`rshift_v`),
     KEY  `realm`  (`realm`),
     KEY  `faction`  (`faction`),
     KEY  `wins`  (`wins`),
     KEY  `losses`  (`losses`),
     KEY  `rating`  (`rating`)
 )  ENGINE=MyISAM  AUTO_INCREMENT=1  DEFAULT  CHARSET=utf8
 PARTITION BY RANGE(`time`)
 (PARTITION  time0  VALUES  LESS  THAN  (10),
   PARTITION  time1  VALUES  LESS  THAN  (20),
   PARTITION  time2  VALUES  LESS  THAN  (30));

в поле  time время из пыха time()

в идеале хочу что бы было 25 частей и в каждую попадал очередной период в 86400 секунд
при создании вылазиет такая ошибка:
 
 #1503 - A PRIMARY KEY must include all columns in the table's partitioning function

ни как не доганю как правильно создать партиции по полю time с данной структурой таблицы
подскажите, что я не правильно делаю?

Это сообщение отредактировал(а) Nick007 - 5.6.2011, 14:40

Раз делишь на партиции по time - он должен быть первичным ключом.
Однако я тебе говорил совсем о другой вещи. Секционирование - это вовсе не деление на партиции...

time дублируется многократно, первичным ключем не может быть, значит партиции отпадают

Если вы удаляете строк больше, чем оставляете, то можно попробовать значительно ускорить сделав:
1. SELECT того, что нужно оставить во временную таблицу
2. TRUNCATE основной таблицы
3. Вставка при disabled keys в основную таблицу из временной
4. Обновление индексов