powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Тормозит ли диск?
36 сообщений из 36, показаны все 2 страниц
Тормозит ли диск?
    #38632401
InterSky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Как определить что узким местом стал именно диск?
Вродк по Profiler не определить что проблема в нём.
Про процессор всегда можно сказать - загружен он на 100% или меньше, и кто кто его грузит, а есть ли какие-то утилиты чтобы определить тоже самое (загруженность диска в процентах и какая программа грузит) под Windows XP? Или это позволяют какие-то внутренние утилиты MySQL?

Тормозит конкретная таблица (на движке MyISAM). Таблица занимает около 18Gb (20 полей Integer, DateTime и VarChar не более 15 символов, и одно Text которое создаёт объём). Таблица очень фрагментирована из-за того что данные переодически подкидываются, и когда дефрагментатор показывает что в ней больше 20 тысчь фрагментов, делаю дефрагментацию всего диска программой Auslogics Disk Defrag Professional с приоритом по свободному месту, так как при дефрагментации обычным дефрагментатором входящим в виндоус и при стандартной дефрагментации Auslogics Disk Defrag Professional этот файл остаётся без изменений и в финальных отчётах так и пишется что осталось несколько дефрагментированных файлов и показывает log-файл из Apache и эту таблицу в каждой из которых несколько тысячь фрагментов (что интересно, даже если я в дефрагментаторе указываю дефрагментировать только один конкретный файл, при этом разумеется на время дефрагментации выключаю сервис MySQL и Apache то эти файлы не дефрагментириуются, а если указываешь что надо весь диск дефрагментировать с приоритетом по свободному месту, тоесть когда он сгоняет все файлы к началу диска и концовку физически оставляет пустой, тогда дефрагментируются и эти файлы). Но по идее эта дефрагментация не должна влиять, так как поиск происходит только по полям которые в индексе, а индексный файл цельный (не фрагментированный), а запрос типа:
Код: sql
1.
select * from Tablica where Data>'2014-05-04' order by ID limit 50


тоесть поиск и сортировка по полям которые в индексе (в этом случае вроде как MySQL даже не будет открывать файл с данными), хотя вроде как при сортировках MySQL задействует диск (именно по этому и считаю что узое место диск).
При простом запросе к такой таблице результат получаю черз 10-15 секунд, а если паралельно запустить почти такой же запрос то оба процесса замерают и комп шуршит диском неизвестно сколько (через 5-10 минут мне обычно надоедало и я через сервисы говорил MySQL-серверу рестартироваться и запускал процессы по отдельности).

P.S. Слышал, что если использовать InodDB, то вроде MySQL сам мледит за фрагментацией всей таблицы (так как она вся хранится в одном файле). Действительно ли это так? Хотя на данный момент перейти на другой движок не могу, хоть и слышал что в последнем MySQL уже и в InodDB есть FullText, но у меня бекапирование осуществляется в виде файлов, так как таблица с 10 миллионами записями копируется за пару минут, а чтобы снять с неё дамп (а тем более восстановить) уходит больше часа...
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38632403
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38633166
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
InterSkyа запрос типа:
Код: sql
1.
select * from Tablica where Data>'2014-05-04' order by ID limit 50



тоесть поиск и сортировка по полям которые в индексе (в этом случае вроде как MySQL даже не будет открывать файл с данными)Откуда такой странный вывод? Во-первых, в индексе явно нет всех полей таблицы, т.е. лазить в в файл с данными придется однозначно. Во-вторых, не глядя в план, вообще не факт, что для этого запроса будет использоваться индекс. Зависит, как минимум, от состава индекса и селективности условия Data>'2014-05-04'.

А за фрагментацией на уровне файловой системы пока рано гоняться, пока еще в MySQL все сыро.
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38633593
InterSky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoftВо-первых, в индексе явно нет всех полей таблицы, т.е. лазить в в файл с данными придется однозначно.Разумеется придётся лазить в файл с данными, но я имел в виду что даже если где-то для выбоки надо сделать перебор по большому поличеству полей - то этот перебор произойдёт по индексному файлу, а уже потом выбронные по ограничению limit 50 будут выбраны из файла с данными, а эта операция произойдёт быстро (тоесть гоняться будет индексный файл).

miksoftВо-вторых, не глядя в план, вообще не факт, что для этого запроса будет использоваться индекс. Зависит, как минимум, от состава индекса и селективности условия Data>'2014-05-04'.Тут, как ни странно вы оказались очень правы, в примере видно что при первом запросе вместо индекса поля по которому ищу используется первичный ключ `ID`.

По поводу экплэйна, вот пример:
Код: sql
1.
explain SELECT * FROM `Tablica` WHERE `Tip` = 'AA' ORDER BY `ID` DESC LIMIT 50;

idselect_typetabletypepossible_keyskeykey_lenrefrowsExtra1SIMPLETablicaindexTipPRIMARY41370Using whereВремя выполнения 3.8 секунды

И тоже самое без лимита:
Код: sql
1.
explain SELECT * FROM `Tablica` WHERE `Tip` = 'AA' ORDER BY `ID` DESC;

idselect_typetabletypepossible_keyskeykey_lenrefrowsExtra1SIMPLETablicarefTipTip12const8765"Using where; Using filesort"Время выполнения 2:31 минуты!!!

При этом если я вместо "SELECT *" напишу "SELECT `ID`" то скорость не меняется (ну бегает в пределах погрешности 2:29-2:36 для второго запроса).

P.S. Размер индексного файла всего 25Мб.
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38633608
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
InterSkyПо поводу экплэйна, вот пример:А причем тут это запрос? Вы показывайте план исходного запроса.

И, кстати, предложите запросам из примера индекс (`Tip`, `ID`).
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38633680
InterSky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoftА причем тут это запрос? Вы показывайте план исходного запроса.
А разве есть какая-то разница? Это всё к одной таблице обращения... Там десятки схожих запросов (везде по индексированному полю), а результат примерно у всех одинаковый: если лимитированный одиночный запрос - то время обработки до 10 секунд, а если запустить 2 запроса одновременно (ну точнее второй запрос запускается до завершения первого), то выполнение идёт больше 10 минут... Или вы так принципиально хотите именно экплэйн с полем типа datetime?

miksoftИ, кстати, предложите запросам из примера индекс (`Tip`, `ID`).
Вы думаете это будет настолько актуально когда индексный файл занимает всего 25Мб?
Я согласен что это облегчит базе поиск по данной связке. Но тогда мне придётся создать сотню новых индексов! (ведь пользователь может искать среди десяти проиндексированных полей, и дальше сортировка может быть тоже по любому из этих полей, в зависимости от того на какую колонку в таблице пользователь нажмёт). А ведь по экплэйну видно что результатом является всего 1000 записей в лимитированном и всего 8000 записей в полном запросе. На сортировку данного количества даже секунды много!
В самой таблице меньше 250 тысячь записей.
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38633702
alex564657498765453
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
InterSky,

если запустить торент, то он показывает внизу предупреждение - шдд перегружен и резко падает скорость передач данных.
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38633707
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
InterSkyА разве есть какая-то разница?Есть.
InterSkyИли вы так принципиально хотите именно экплэйн с полем типа datetime?Я "принципиально" ничего не хочу. Вы показали проблемный запрос, а разбираться в нем не хотите. А мы, даже при всем желании, не можем из-за недостатка информации.


InterSkymiksoftИ, кстати, предложите запросам из примера индекс (`Tip`, `ID`).
Вы думаете это будет настолько актуально когда индексный файл занимает всего 25Мб?Актуальность слабо связана с расзмером индексного файла. Если текущее быстродействие устраивает, то и не трогайте.
Индекс я предлагал больше в исследовательских целях.

InterSkyА ведь по экплэйну видно что результатом является всего 1000 записей в лимитированном и всего 8000 записей в полном запросе. На сортировку данного количества даже секунды много! InterSkyТаблица занимает около 18GbInterSkyВ самой таблице меньше 250 тысячь записей.Вообще-то это несколько сотен мегабайт. И за секунду их никак не отсортируешь.
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38633820
InterSky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoftЯ "принципиально" ничего не хочу. Вы показали проблемный запрос, а разбираться в нем не хотите. А мы, даже при всем желании, не можем из-за недостатка информации.Может вы имеете ввиду структуру таблицы? Или что тогда имеете в виду под фразой "план исходного запроса", раз explain не устроил?


miksoftИндекс я предлагал больше в исследовательских целях.Я постараюсь ночью сделать. При изменении индекса MySQL ведь будет физически пересоздавать всю таблицу, а это по времени долго (да и откровенно говоря у меня сейчас нет столько свободного места). Другое дело что после дефрагментации скорость увеличивается в разы (но за день-два опять падает из-за увеличения фрагментирования файла).


miksoftInterSky...Таблица занимает около 18Gb...
...В самой таблице меньше 250 тысячь записей...
...результатом выборки является всего 1000 записей...
На сортировку данного количества даже секунды много! Вообще-то это несколько сотен мегабайт. И за секунду их никак не отсортируешь.Не соглашусь (или вы можете более равёрнуто аргументировать такую скорость?)
Да, записи большие. Но я рассказывал структуру: десяток коротких полей Integer, VarChar, DateTime и одно Text более 60Кб.
Но:
1) Я говорил что если меняю " SELECT * from ... " на " SELECT ID from ... ", то время практически НЕ меняется.
2) Разве сортирока производится всего набора данных? Почему-то я уверен что вначале в индексном файле выбираются все записи соответсвующие `Tip` = 'AA', затем из индексного же файла берутся значения поля `ID` и происходит сортировка, а уже затем из файла с данными достаются сами данные и передаются на выход... Или вы хотите сказать что MySQL собирает неотсортированный набор 8000*60Кб=480Мб и потом 2 минуты сортирует их на жёстком диске? (хотя в случае с select ID from объём выборки и мегабайта не займёт).
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38633830
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
InterSkymiksoftЯ "принципиально" ничего не хочу. Вы показали проблемный запрос, а разбираться в нем не хотите. А мы, даже при всем желании, не можем из-за недостатка информации.Может вы имеете ввиду структуру таблицы? Или что тогда имеете в виду под фразой "план исходного запроса", раз explain не устроил?Вы план исходного запроса (т.е. explain) не показывали. Именно этим он и не устроил :)
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38633831
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
InterSkyРазве сортирока производится всего набора данных?К сожалению, да. По крайней мере, обратной ситуации мне не доводилось наблюдать.
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38633963
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а что покажет
Код: sql
1.
explain select  * from (SELECT * FROM `Tablica` WHERE `Tip` = 'AA' ) as a ORDER BY a.`ID` DESC;
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38641396
InterSky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Из-за отсутсвия свободных 18Гб мне так и не удалось добавить двойной индекс чтобы проверить насколько изменится производительность при нём (хотя как я говорил - это не будет решением, так как я не могу поставить двойные индексы по всем вариантам поиск+сортировка).
Но зато за ночь я сделал дефрагментацию (как я уже говорил ранее - реально дефрагментировать файл Tablica.MYD может только Auslogics Disk Defrag Professional и исключительно в режиме Free space optimization, потому что в обычном режиме большие файлы с большим количеством фрагментов полностью игронирует как стандартный дефрагментатор виндоуса, так и используемый мной Auslogics Disk Defrag Professional даже если я указываю что мне надо дефрагментировать только один мой конкретный файл).

Итак после дефрагментации запрос выплняемый за "2:31 минуты" стал выплняться за 0.6 секунды, а лимитированный который выполнялся "3.8 секунды" стал выполняться за 0.02 секунды. Но это сразу после дефрагментации, а спустя пару дней всё вернулось примерно к прежним тормозным скоростям.

Сегодня даже был случай: запустил цикл апдейтов:
Код: sql
1.
update Tablica set PoleMemo='...' where ID=...

(ясное дело вместо "..." подставляются разные значения)
Обновления выполнялись быстро (там куча расчётов по этому скорость 3-4 обновления в секунду считаю отличной), и паралельно запустил лимитированный запрос:
Код: sql
1.
SELECT * FROM `Tablica` WHERE `Tip` = 'AA' ORDER BY `ID` DESC LIMIT 50;

(который в самые плохие времена выполняется за несколько секунд, а после дефрагментации как писал выше - выполнился за 0.02 секунды), и после запуска этого запроса всё повисло на 12 минут!!! Я подключился к MySQL через третий клиент и смотрел SHOW FULL PROCESSLIST - время выполнения у update и select запросов было одинаковое (тоесть за время сэлэкта не проскочил ни один апдэйт). Причём всё это время (все 12 минут) компьютер нещадно молотил жёстким диском... А нагрузка на процессор была почти нулевой (mysqld иногда поднимался до 2% процессорного времени, а больше ничего и не работало).
Может есть какая-то утилита под виндоус которая показывает с каким конкретным файлом работает программа и сколько раз обращалась, чтобы понять - или это идёт выборка данных из таблицы, или это сортировка в файле, или это ещё непонятно что? Упомянутый тут AnVir показывает общую нагрузку на диск (как впрочем и встроенный в виндоус PerfMon.msc)

Для вадя :
Вот результат выполнения вашего запроса:
Код: sql
1.
explain select  * from (SELECT * FROM `Tablica` WHERE `Tip` = 'AA' ) as a ORDER BY a.`ID` DESC;

idselect_typetabletypepossible_keyskeykey_lenrefrowsExtra1PRIMARY<derived2>ALL11017Using filesort2DERIVEDTablicarefTipTip128087Using whereПричём этот экплэйн выполнялся 2 минуты 3 секунды.

На всякий случай напишу и структуру таблицы:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
CREATE TABLE `Tablica` (
  `ID` int(11) NOT NULL AUTO_INCREMENT,
  `Data` datetime DEFAULT NULL,
  `HTML` text,
  `Status` varchar(3),
  `Koment` varchar(255),
  `Tip` varchar(3),
  `Kto` varchar(25),
  `Kuda` varchar(25),
  `Plan` text,
  `Resurs` varchar(20),
  `PoleMemo` text,
  `Kat` char(1),
  `R2` char(1),
  `x` char(1),
  PRIMARY KEY (`Nr`),
  KEY `Status` (`Status`),
  KEY `Tip` (`Tip`),
  KEY `Kto` (`Kuda`),
  KEY `Kuda` (`Kuda`),
  KEY `Kat` (`Kat`),
  KEY `x` (`x`)
) ENGINE=MyISAM;

Количество записей: более 300 тысячь
Размер файла Tablica.MYD: более 20Gb
Размер файла Tablica.MYI: всего 28Мб
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38641404
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
InterSky,

По полю `Data` нет индекса?
Тогда откуда вот это:
InterSky
Код: sql
1.
select * from Tablica where Data>'2014-05-04' order by ID limit 50



тоесть поиск и сортировка по полям которые в индексе???
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38641476
InterSky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Есть индекс по полю Data, я просто чтобы небыло очень длинно стёр повторяющиеся строки:
Код: sql
1.
2.
3.
4.
5.
  `Prim1` varchar(10),
  `Prim2` varchar(10),
  `Prim3` varchar(10),
...
  `Prim20` varchar(10),


и их индексы, случайно захватив и индекс по дате... Хотя по дате очень редко ищется и сортируется (восновном по ID), по этому после первого примера который я привёл в описании проблемы, я давал уже более частые запросы.
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38641509
Cygapb-007
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
InterSkyНа всякий случай напишу и структуру таблицы:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
CREATE TABLE `Tablica` (
  `ID` int(11) NOT NULL AUTO_INCREMENT,
  `Data` datetime DEFAULT NULL,
  `HTML` text,
  `Status` varchar(3),
  `Koment` varchar(255),
  `Tip` varchar(3),
  `Kto` varchar(25),
  `Kuda` varchar(25),
  `Plan` text,
  `Resurs` varchar(20),
  `PoleMemo` text,
  `Kat` char(1),
  `R2` char(1),
  `x` char(1),
  PRIMARY KEY (`Nr`),
  KEY `Status` (`Status`),
  KEY `Tip` (`Tip`),
  KEY `Kto` (`Kuda`),
  KEY `Kuda` (`Kuda`),
  KEY `Kat` (`Kat`),
  KEY `x` (`x`)
) ENGINE=MyISAM;

Количество записей: более 300 тысячь
Размер файла Tablica.MYD: более 20Gb
Размер файла Tablica.MYI: всего 28МбУ вас специально ID не первичный ключ? Если так, то
1) при поиске по Data в индексе (Data) будет найдено значение Nr
2) для получения значения Id придется искать его во всей таблице (по кластерному индексу) по значению Kr
3) для сортировки по Id свопировать результаты поиска на диск и там сортировать

Если бы Id был PK:
1) при поиске по Data в индексе (Data) будет найдено значение Id
2) для сортировки по Id свопировать результаты поиска на диск и там сортировать, т.к. поиск был по другому индексу.

Если PK=Nr, индекс (Data,Id):
1) при поиске по Data в индексе (Data,Id) будет сразу найдено значение Id
2) для сортировки по Id свопировать результаты поиска на диск и там сортировать, т.к. поиск был по другому индексу.

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

Если индекс не покрывающий, то в любом варианте (кроме первого - там уже есть) понадобится поиск в кластерном индексе для извлечения необходимых значений (указанных в SELECT)
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38641510
Cygapb-007
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
* указанных во всем запросе (SELECT, WHERE, ON и т.д.)
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38641511
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cygapb-007У вас специально ID не первичный ключ? Если так, то
1) при поиске по Data в индексе (Data) будет найдено значение Nr
2) для получения значения Id придется искать его во всей таблице (по кластерному индексу) по значению Kr
3) для сортировки по Id свопировать результаты поиска на диск и там сортироватьОбратите внимание, тут MyISAM.
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38641512
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторУпомянутый тут AnVir показывает общую нагрузку на диск (как впрочем и встроенный в виндоус PerfMon.msc)

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

похоже у тебя всё упирается влисковую ситему
кстати Auslogics Disk Defrag позволяет посмотреть, если задать деврагментаци. 1 фала, и количество фрагментов и их расположение на диске

у дисков с системе есть параметр, галочка, как использовать кеш. также интересно, можно посмотреть в диспетчере задач, как используется память и своп. а сколько памяти в ХР? и чему равен своп файл?
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38641513
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хотя расхождение все равно странное...
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38641516
Cygapb-007
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoftCygapb-007У вас специально ID не первичный ключ? Если так, то
1) при поиске по Data в индексе (Data) будет найдено значение Nr
2) для получения значения Id придется искать его во всей таблице (по кластерному индексу) по значению Kr
3) для сортировки по Id свопировать результаты поиска на диск и там сортироватьОбратите внимание, тут MyISAM.ыыы ...
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38641555
Cygapb-007
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoftХотя расхождение все равно странное...Я неправильно трактую работу с индексами в MySQL?
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38641567
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cygapb-007miksoftХотя расхождение все равно странное...Я неправильно трактую работу с индексами в MySQL?То, что Вы написали, верно для InnoDB, но не для MyISAM.
В MyISAM обычная таблица-куча, а не кластерный индекс.

А под расхождением я имел в виду, что автоинкрементное поле одно, а в первичном ключе другое. Да еще которого нет в определении таблицы.
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38641660
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
автор`Kto` varchar(25),
`Kuda` varchar(25),

третья нормальная форма плачет кровавыми слезами.
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38641687
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ScareCrowавтор`Kto` varchar(25),
`Kuda` varchar(25),

третья нормальная форма плачет кровавыми слезами.

и причина разбухания файла
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38642579
InterSky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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) сортировка не требуется (отсортировано индексом)
Не факт, что этот алгоритм будет эффективнее, но попробовать можно :)Вот об этом ни разу не думал (что иногда может быть выгодней просканировать весь индекс перебором, но зато потом выиграть на отсутсвии сортировки). Спасибо!
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38642633
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я бы предложил попробовать довольно сложный вариант:
1) вынести все поля типа TEXT и все остальные поля, по которым никогда не будет осуществляться фильтрация, в отдельную дополнительную таблицу.
2) оставшиеся поля преобразовать к типу, занимающему фиксированный объем, например, varchar в char
3) переписать запросы так, чтобы соединение с дополнительной таблице происходило только после отбора записей (включая LIMIT) по основной таблице.

К сожалению, недостаточно данных, чтобы утверждать, что этот вариант что-то улучшит, но вероятность есть.
В частности, непонятен характер регулярных апдейтов.
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38642725
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
присоединяюсь к miksoft
это будет полезная и интересная информация.
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38651513
InterSky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я обещаю сделать как предложил miksoft потому что тоже уверен что дело в Text полях.
Но только попозже, потому что сейчас у меня нету столько места на диске (чтобы создать вторую таблицу такого же объёма).

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

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

И ещё хотел спросить у гуру работающих с Profiler - а там случайно нету возможности узнать если я сделал единичный запрос, сколько времени ушло на работу с индексом, сколько на работу с файлом данных, и сколько на сортировку? (ну или прочитанный объъём в байтах из файла индекса, файла данных, и временно файла для сортировки)
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38651663
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
InterSky, ну вы все правильно думаете. некоторые значения косвенно можно узнать по разности счетчиков. dbforge при профилировании подсчитывает эту разность и выводит. Но насчет влияние фрагментации - нет нельзя. Нет таких счетчиков.

На мой взгляд, эффект от OPTIMIZE обычно неверно оценивается. Он заключается в кратковременном засасывании содержимого таблицы в кеш ОС. Запросы на некоторое время ускоряются, но потом все равно замедляются. Я бы не стал туда копать.
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38651921
InterSky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Разве OPTIMIZE не пересоздат таблицу заново выкинув оттуда все пустые блоки, упорядочив и соединив данные? (я правда не знаю - может ли запись внутри файла.MYD делиться на фрагменты, или же она просто "перезаписывается в конец файла" или "в свободный фрагмент необходимого размера внутри" но целиком?
Тоесть если у меня есть файл с тремя записями:
1111111111111112222223333333333
и мне надо увеличить запись "2" на несколько байтов, произойдёт дписывание неуместившегося фрагмента в конец:
111111111111111 222222 3333333333 222
или переписывание целиком?
111111111111111 .......... 3333333333 222222222
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38651926
tanglir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
InterSky,

ЕМНИП целиком
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38651959
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
InterSkyТоесть если у меня есть файл с тремя записями:
1111111111111112222223333333333
и мне надо увеличить запись "2" на несколько байтов, произойдёт дписывание неуместившегося фрагмента в конец:
111111111111111 222222 3333333333 222
или переписывание целиком?
111111111111111 .......... 3333333333 222222222 Насколько я в курсе, целиком. Нигде не встречал упоминания, что MySQL умеет делить записи на фрагменты.
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38652483
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
InterSky, и что значит "Разве" ? высказанного мной это не отменяет.

"на глазок" нефрагментированная база на 10гб тормозит примерно так же как и фрагментированная на 12гб.
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38652512
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Покажите план
Код: sql
1.
Select ID from ...


А не
Код: sql
1.
Select * from ...


И поймем все сразу...
...
Рейтинг: 0 / 0
Тормозит ли диск?
    #38652517
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И действительно, не используйте в MySQL varchar, это точно не для вашей ситуации.
...
Рейтинг: 0 / 0
36 сообщений из 36, показаны все 2 страниц
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Тормозит ли диск?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]