Форум пользователей MySQL

paulus написал:

В голову приходит только то, что оно не зависает, а начинает считать индекс.
Также может, например, кончаться место (в т.ч. и во временном хранилище).

место нет, не заканчивается. Насчет индекса - если он и считает его, то очень медленно и без какой либо активности процессором. Я бы оставил его считать себе дальше, но из за набегания висящих запросов в temporary table  вешается все остальное, а там куча важных сервисов.

paulus написал:

Насколько часто заполняется эта табличка? Может, сразу сделать индекс и
делать REPLACE в нее? Если одноразовая — нет ли там какой-то неявной сор-
тировки (например, не сортированы ли уже строки по ключу физически)?

Можно сделать сразу. Но скрипт который генерит эту БД генерит ее _намного_ дольше. Если без индексов время примерно 12 часов, то с индексами время удваивается. Мне изначально казалось, что генерация без индексов + INSERT + SELECT -должна работать гораздо быстрее, я даже не предполагал что наткнусь на такую проблему.

Если никаких других вариантов не придет в голову, придется так и оставить. Насчет сортировки не понял. Таблица делается с нуля.

P.S. Вот думаю, насколько полезно temp мускуля выносить на отдельный диск/массив? На сервере сейчас три райд массива
1. raid1 (75Gb, SAS),
2. raid10 (600Gb, SAS)
3. raid1 (750Gb, SATA).

mysql лежит на 2 массиве, там же и все БД, там же и его temp. 1 массив - система, 3 - файлопомойка, оба загружены весьма слабо. Имеет ли смысл перенести temp и если да, то на какой - побольше или побыстрее ?

Да в том то и дело, что ничего подозрительного не наблюдается. Буду дальше наблюдать, либо скриптом геренить вместе с индексами...

Есть еще одна мысль. Почему я вставляю в таблицу без индексов - чтобы скрипт отрабатывал как можно быстрее. Скрипт обрабатывает пачку XML-файлов (тысяч десять в каждом по 10 тысяч записей), соответственно по одному запросу на файл INSERT INTO t1 VALUES (),(),(),()... Что если сделать так: сделать 2 таблицы t1 и t2. Первая без индексов, вторая с.  На t1 повесить триггер на INSERT, который после получения каждого запроса будет лочить 1 таблицу, переносить во вторую (с индексами), после чего первую чистить. Есть ли шанс, что так будет быстрее, чем просто вставлять в одну индексированную?

А что насчет вопроса про райды?

paulus написал:

Если переделать не получается (i.e. обработка
всех данных в огромной таблице), то тогда быстрые диски лучше медленных

Это я понимаю. Тут вопрос немного по другому поводу... сейчас все базы данных и временный каталог расположены на самом быстром райде, но при этом ведь происходит чтение и запись с одного носителя одновременно, поэтому и интересно не стоит ли выносить темп пусть даже на более медленный диск, но отдельный. Поставил process monitor, посмотрел чем занимается mysql (немного прифигел от увиденного ). Видимо был неправ, считая что процесс висит - он просто долго туда пишет, а изменения размера происходят нечасто. Но пишет он только в t2.MYD и ни в какие временные таблицы, тогда непонятно почему это мешает другие процессам писать в tmp.
Еще заметил странную вещь - почему то одни временные таблицы создаются в temp/, а другие в каталоге data/ (т.е. в корне) а третьи в каталогах самих баз данных. Отчего так, почему mysql не всегда использует указанный ему каталог для временных файлов?

Ну как, своими глазами наблюдаю:

Date: 07.07.2010 21:04:30
Thread: 664
Class: File System
Operation: WriteFile
Result: SUCCESS
Path: E:\home\mysql\data\#sql_6dc_13.MYD
Duration: 0.0074455

Вот вроде бы такой:

Отредактированно Shopen (07.07.2010 21:41:21)

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