Cygapb-007У вас специально ID не первичный ключ?Опять опечатка с моей стороны :(
ID = Nr
В одной строке переименовал название, а в другой забыл. Так было проще объяснять когда показывал пример. Чтобы небыло лишних вопросов, ведь когда ты видишь поле ID ты сразу же понимаешь что это первичный ключь... Ну и тут решил подправить чтобы совпадало с ранее приведёнными примерами. А вышло наоборот - рассуждения ушли в сторону. Наверно зря дал исходник таблицы, всё основное было сказано в первых строках первого топика - " ...на движке MyISAM). Таблица занимает около 18Gb (20 полей Integer, DateTime и VarChar не более 15 символов, и одно Text которое создаёт объём). Таблица очень фрагментирована... "


ScareCrowавтор`Kto` varchar(25),
`Kuda` varchar(25),третья нормальная форма плачет кровавыми слезами.Ничего страшного... Видя скорость поиска по индексу, при JOIN вообще повеситься можно будет...



вадяScareCrowтретья нормальная форма плачет кровавыми слезами.и причина разбухания файлаДаже если бы эти поля были бы полностью заполнены, они бы занимали всего (25+25)*300т = 15 мегабайт, что на фоне более чем 20 Гигабайтной базы не так и много. Ну а в реальности эти поля далеко не всегда заполнены, и объём не создают. Основной объём создаёт поле HTML.


Cygapb-007Если бы Id был PK:
1) при поиске по Data в индексе (Data) будет найдено значение Id
2) для сортировки по Id свопировать результаты поиска на диск и там сортировать, т.к. поиск был по другому индексу.Раз уж сказал что ID является первичным ключём, значит это именно этот вариант. Но проблема всё равно где-то не тут. Иначем почему одновременное выполнение update и select занимает 12 минут (хотя по отдельности update выполняется примерно 0.3 секунды, а select около 3 секунд). При этом за эти 12 минут ни один update не выполнился, как говорил выше - оба запроса висели в SHOW FULL PROCESSLIST, а диск всё это время бешенно шуршал...
В целом проблема наверно именно в сортировке на диске, ведь если я не указываю order by поскольку база и так выдаётся по первичному ключу (хотя конечно знаю что это не гарантированно и сам видел в живую как MySQL при select * from X выдал все 5 строк из базы в порядке 1,5,2,3,4, а при повторном запуске запроса уже 1,2,3,4,5), так вот, если без order by то запрос на который раньше уходило несколько минут получаю за секунду...
В my.ini ничего не менял, там изначально стоит:
myisam_max_sort_file_size=100G
myisam_sort_buffer_size=8M


Cygapb-007Если индекс (Id,Data):
1) поиск сканированием всего индекса требуемых значений Data
2) сортировка не требуется (отсортировано индексом)
Не факт, что этот алгоритм будет эффективнее, но попробовать можно :)Вот об этом ни разу не думал (что иногда может быть выгодней просканировать весь индекс перебором, но зато потом выиграть на отсутсвии сортировки). Спасибо!

Я обещаю сделать как предложил miksoft потому что тоже уверен что дело в Text полях.
Но только попозже, потому что сейчас у меня нету столько места на диске (чтобы создать вторую таблицу такого же объёма).

У меня правда появилась своя идея - возможно медленная скорость получения данных является следсвием ВНУТРЕННЕЙ дефрагментованности самого файла Tablica.MYD, поскольку к каждой внесённой в таблицу строке в последствии будет произведён Update (дополнение информацией расчитанной на основании внесённых вначале данных). Дополнительных данных не много, но они ведь увеличивают объём записи, а следовательно MySQL вынужден увеличивать хвост файла. Тоесть возможно после выполнения OPTIMIZE TABLE ситуация улучшится в разы...

Я в какой-то момент уже поверил что тормозит именно сортировка, но запросты типа select ID from... время практически не уменьшают. По этому сейчас считаю что проблема в извлечении данных из разфрагментированных записей.

И ещё хотел спросить у гуру работающих с Profiler - а там случайно нету возможности узнать если я сделал единичный запрос, сколько времени ушло на работу с индексом, сколько на работу с файлом данных, и сколько на сортировку? (ну или прочитанный объъём в байтах из файла индекса, файла данных, и временно файла для сортировки)

Разве OPTIMIZE не пересоздат таблицу заново выкинув оттуда все пустые блоки, упорядочив и соединив данные? (я правда не знаю - может ли запись внутри файла.MYD делиться на фрагменты, или же она просто "перезаписывается в конец файла" или "в свободный фрагмент необходимого размера внутри" но целиком?
Тоесть если у меня есть файл с тремя записями:
1111111111111112222223333333333
и мне надо увеличить запись "2" на несколько байтов, произойдёт дписывание неуместившегося фрагмента в конец:
111111111111111 222222 3333333333 222
или переписывание целиком?
111111111111111 .......... 3333333333 222222222