|
|
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
Как определить что узким местом стал именно диск? Вродк по 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. тоесть поиск и сортировка по полям которые в индексе (в этом случае вроде как MySQL даже не будет открывать файл с данными), хотя вроде как при сортировках MySQL задействует диск (именно по этому и считаю что узое место диск). При простом запросе к такой таблице результат получаю черз 10-15 секунд, а если паралельно запустить почти такой же запрос то оба процесса замерают и комп шуршит диском неизвестно сколько (через 5-10 минут мне обычно надоедало и я через сервисы говорил MySQL-серверу рестартироваться и запускал процессы по отдельности). P.S. Слышал, что если использовать InodDB, то вроде MySQL сам мледит за фрагментацией всей таблицы (так как она вся хранится в одном файле). Действительно ли это так? Хотя на данный момент перейти на другой движок не могу, хоть и слышал что в последнем MySQL уже и в InodDB есть FullText, но у меня бекапирование осуществляется в виде файлов, так как таблица с 10 миллионами записями копируется за пару минут, а чтобы снять с неё дамп (а тем более восстановить) уходит больше часа... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.05.2014, 15:37:58 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
InterSkyа запрос типа: Код: sql 1. тоесть поиск и сортировка по полям которые в индексе (в этом случае вроде как MySQL даже не будет открывать файл с данными)Откуда такой странный вывод? Во-первых, в индексе явно нет всех полей таблицы, т.е. лазить в в файл с данными придется однозначно. Во-вторых, не глядя в план, вообще не факт, что для этого запроса будет использоваться индекс. Зависит, как минимум, от состава индекса и селективности условия Data>'2014-05-04'. А за фрагментацией на уровне файловой системы пока рано гоняться, пока еще в MySQL все сыро. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2014, 13:27:56 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
miksoftВо-первых, в индексе явно нет всех полей таблицы, т.е. лазить в в файл с данными придется однозначно.Разумеется придётся лазить в файл с данными, но я имел в виду что даже если где-то для выбоки надо сделать перебор по большому поличеству полей - то этот перебор произойдёт по индексному файлу, а уже потом выбронные по ограничению limit 50 будут выбраны из файла с данными, а эта операция произойдёт быстро (тоесть гоняться будет индексный файл). miksoftВо-вторых, не глядя в план, вообще не факт, что для этого запроса будет использоваться индекс. Зависит, как минимум, от состава индекса и селективности условия Data>'2014-05-04'.Тут, как ни странно вы оказались очень правы, в примере видно что при первом запросе вместо индекса поля по которому ищу используется первичный ключ `ID`. По поводу экплэйна, вот пример: Код: sql 1. idselect_typetabletypepossible_keyskeykey_lenrefrowsExtra1SIMPLETablicaindexTipPRIMARY41370Using whereВремя выполнения 3.8 секунды И тоже самое без лимита: Код: sql 1. idselect_typetabletypepossible_keyskeykey_lenrefrowsExtra1SIMPLETablicarefTipTip12const8765"Using where; Using filesort"Время выполнения 2:31 минуты!!! При этом если я вместо "SELECT *" напишу "SELECT `ID`" то скорость не меняется (ну бегает в пределах погрешности 2:29-2:36 для второго запроса). P.S. Размер индексного файла всего 25Мб. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2014, 17:33:20 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
InterSkyПо поводу экплэйна, вот пример:А причем тут это запрос? Вы показывайте план исходного запроса. И, кстати, предложите запросам из примера индекс (`Tip`, `ID`). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2014, 17:46:10 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
miksoftА причем тут это запрос? Вы показывайте план исходного запроса. А разве есть какая-то разница? Это всё к одной таблице обращения... Там десятки схожих запросов (везде по индексированному полю), а результат примерно у всех одинаковый: если лимитированный одиночный запрос - то время обработки до 10 секунд, а если запустить 2 запроса одновременно (ну точнее второй запрос запускается до завершения первого), то выполнение идёт больше 10 минут... Или вы так принципиально хотите именно экплэйн с полем типа datetime? miksoftИ, кстати, предложите запросам из примера индекс (`Tip`, `ID`). Вы думаете это будет настолько актуально когда индексный файл занимает всего 25Мб? Я согласен что это облегчит базе поиск по данной связке. Но тогда мне придётся создать сотню новых индексов! (ведь пользователь может искать среди десяти проиндексированных полей, и дальше сортировка может быть тоже по любому из этих полей, в зависимости от того на какую колонку в таблице пользователь нажмёт). А ведь по экплэйну видно что результатом является всего 1000 записей в лимитированном и всего 8000 записей в полном запросе. На сортировку данного количества даже секунды много! В самой таблице меньше 250 тысячь записей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2014, 18:50:04 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
InterSky, если запустить торент, то он показывает внизу предупреждение - шдд перегружен и резко падает скорость передач данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2014, 19:19:35 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
InterSkyА разве есть какая-то разница?Есть. InterSkyИли вы так принципиально хотите именно экплэйн с полем типа datetime?Я "принципиально" ничего не хочу. Вы показали проблемный запрос, а разбираться в нем не хотите. А мы, даже при всем желании, не можем из-за недостатка информации. InterSkymiksoftИ, кстати, предложите запросам из примера индекс (`Tip`, `ID`). Вы думаете это будет настолько актуально когда индексный файл занимает всего 25Мб?Актуальность слабо связана с расзмером индексного файла. Если текущее быстродействие устраивает, то и не трогайте. Индекс я предлагал больше в исследовательских целях. InterSkyА ведь по экплэйну видно что результатом является всего 1000 записей в лимитированном и всего 8000 записей в полном запросе. На сортировку данного количества даже секунды много! InterSkyТаблица занимает около 18GbInterSkyВ самой таблице меньше 250 тысячь записей.Вообще-то это несколько сотен мегабайт. И за секунду их никак не отсортируешь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2014, 19:23:23 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
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 объём выборки и мегабайта не займёт). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2014, 21:30:01 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
InterSkymiksoftЯ "принципиально" ничего не хочу. Вы показали проблемный запрос, а разбираться в нем не хотите. А мы, даже при всем желании, не можем из-за недостатка информации.Может вы имеете ввиду структуру таблицы? Или что тогда имеете в виду под фразой "план исходного запроса", раз explain не устроил?Вы план исходного запроса (т.е. explain) не показывали. Именно этим он и не устроил :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2014, 21:44:12 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
InterSkyРазве сортирока производится всего набора данных?К сожалению, да. По крайней мере, обратной ситуации мне не доводилось наблюдать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2014, 21:45:13 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
а что покажет Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2014, 02:35:48 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
Из-за отсутсвия свободных 18Гб мне так и не удалось добавить двойной индекс чтобы проверить насколько изменится производительность при нём (хотя как я говорил - это не будет решением, так как я не могу поставить двойные индексы по всем вариантам поиск+сортировка). Но зато за ночь я сделал дефрагментацию (как я уже говорил ранее - реально дефрагментировать файл Tablica.MYD может только Auslogics Disk Defrag Professional и исключительно в режиме Free space optimization, потому что в обычном режиме большие файлы с большим количеством фрагментов полностью игронирует как стандартный дефрагментатор виндоуса, так и используемый мной Auslogics Disk Defrag Professional даже если я указываю что мне надо дефрагментировать только один мой конкретный файл). Итак после дефрагментации запрос выплняемый за "2:31 минуты" стал выплняться за 0.6 секунды, а лимитированный который выполнялся "3.8 секунды" стал выполняться за 0.02 секунды. Но это сразу после дефрагментации, а спустя пару дней всё вернулось примерно к прежним тормозным скоростям. Сегодня даже был случай: запустил цикл апдейтов: Код: sql 1. (ясное дело вместо "..." подставляются разные значения) Обновления выполнялись быстро (там куча расчётов по этому скорость 3-4 обновления в секунду считаю отличной), и паралельно запустил лимитированный запрос: Код: sql 1. (который в самые плохие времена выполняется за несколько секунд, а после дефрагментации как писал выше - выполнился за 0.02 секунды), и после запуска этого запроса всё повисло на 12 минут!!! Я подключился к MySQL через третий клиент и смотрел SHOW FULL PROCESSLIST - время выполнения у update и select запросов было одинаковое (тоесть за время сэлэкта не проскочил ни один апдэйт). Причём всё это время (все 12 минут) компьютер нещадно молотил жёстким диском... А нагрузка на процессор была почти нулевой (mysqld иногда поднимался до 2% процессорного времени, а больше ничего и не работало). Может есть какая-то утилита под виндоус которая показывает с каким конкретным файлом работает программа и сколько раз обращалась, чтобы понять - или это идёт выборка данных из таблицы, или это сортировка в файле, или это ещё непонятно что? Упомянутый тут AnVir показывает общую нагрузку на диск (как впрочем и встроенный в виндоус PerfMon.msc) Для вадя : Вот результат выполнения вашего запроса: Код: sql 1. 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. Количество записей: более 300 тысячь Размер файла Tablica.MYD: более 20Gb Размер файла Tablica.MYI: всего 28Мб ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2014, 17:55:23 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
InterSky, По полю `Data` нет индекса? Тогда откуда вот это: InterSky Код: sql 1. тоесть поиск и сортировка по полям которые в индексе??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2014, 18:03:20 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
Есть индекс по полю Data, я просто чтобы небыло очень длинно стёр повторяющиеся строки: Код: sql 1. 2. 3. 4. 5. и их индексы, случайно захватив и индекс по дате... Хотя по дате очень редко ищется и сортируется (восновном по ID), по этому после первого примера который я привёл в описании проблемы, я давал уже более частые запросы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2014, 19:35:51 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
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. Количество записей: более 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) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2014, 20:28:22 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
* указанных во всем запросе (SELECT, WHERE, ON и т.д.) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2014, 20:30:36 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
Cygapb-007У вас специально ID не первичный ключ? Если так, то 1) при поиске по Data в индексе (Data) будет найдено значение Nr 2) для получения значения Id придется искать его во всей таблице (по кластерному индексу) по значению Kr 3) для сортировки по Id свопировать результаты поиска на диск и там сортироватьОбратите внимание, тут MyISAM. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2014, 20:32:03 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
авторУпомянутый тут AnVir показывает общую нагрузку на диск (как впрочем и встроенный в виндоус PerfMon.msc) если у него раскрыть ,по на жатию в систрее иконки с дисками, откроется окно где будет показываться и проги загружающие диск похоже у тебя всё упирается влисковую ситему кстати Auslogics Disk Defrag позволяет посмотреть, если задать деврагментаци. 1 фала, и количество фрагментов и их расположение на диске у дисков с системе есть параметр, галочка, как использовать кеш. также интересно, можно посмотреть в диспетчере задач, как используется память и своп. а сколько памяти в ХР? и чему равен своп файл? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2014, 20:33:07 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
Хотя расхождение все равно странное... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2014, 20:33:16 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
miksoftCygapb-007У вас специально ID не первичный ключ? Если так, то 1) при поиске по Data в индексе (Data) будет найдено значение Nr 2) для получения значения Id придется искать его во всей таблице (по кластерному индексу) по значению Kr 3) для сортировки по Id свопировать результаты поиска на диск и там сортироватьОбратите внимание, тут MyISAM.ыыы ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2014, 20:39:12 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
miksoftХотя расхождение все равно странное...Я неправильно трактую работу с индексами в MySQL? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2014, 22:06:42 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
Cygapb-007miksoftХотя расхождение все равно странное...Я неправильно трактую работу с индексами в MySQL?То, что Вы написали, верно для InnoDB, но не для MyISAM. В MyISAM обычная таблица-куча, а не кластерный индекс. А под расхождением я имел в виду, что автоинкрементное поле одно, а в первичном ключе другое. Да еще которого нет в определении таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2014, 22:16:02 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
автор`Kto` varchar(25), `Kuda` varchar(25), третья нормальная форма плачет кровавыми слезами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2014, 01:36:02 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
ScareCrowавтор`Kto` varchar(25), `Kuda` varchar(25), третья нормальная форма плачет кровавыми слезами. и причина разбухания файла ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2014, 06:00:40 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
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) сортировка не требуется (отсортировано индексом) Не факт, что этот алгоритм будет эффективнее, но попробовать можно :)Вот об этом ни разу не думал (что иногда может быть выгодней просканировать весь индекс перебором, но зато потом выиграть на отсутсвии сортировки). Спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2014, 17:18:12 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
Я бы предложил попробовать довольно сложный вариант: 1) вынести все поля типа TEXT и все остальные поля, по которым никогда не будет осуществляться фильтрация, в отдельную дополнительную таблицу. 2) оставшиеся поля преобразовать к типу, занимающему фиксированный объем, например, varchar в char 3) переписать запросы так, чтобы соединение с дополнительной таблице происходило только после отбора записей (включая LIMIT) по основной таблице. К сожалению, недостаточно данных, чтобы утверждать, что этот вариант что-то улучшит, но вероятность есть. В частности, непонятен характер регулярных апдейтов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2014, 17:52:47 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
присоединяюсь к miksoft это будет полезная и интересная информация. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2014, 19:13:16 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
Я обещаю сделать как предложил miksoft потому что тоже уверен что дело в Text полях. Но только попозже, потому что сейчас у меня нету столько места на диске (чтобы создать вторую таблицу такого же объёма). У меня правда появилась своя идея - возможно медленная скорость получения данных является следсвием ВНУТРЕННЕЙ дефрагментованности самого файла Tablica.MYD, поскольку к каждой внесённой в таблицу строке в последствии будет произведён Update (дополнение информацией расчитанной на основании внесённых вначале данных). Дополнительных данных не много, но они ведь увеличивают объём записи, а следовательно MySQL вынужден увеличивать хвост файла. Тоесть возможно после выполнения OPTIMIZE TABLE ситуация улучшится в разы... Я в какой-то момент уже поверил что тормозит именно сортировка, но запросты типа select ID from... время практически не уменьшают. По этому сейчас считаю что проблема в извлечении данных из разфрагментированных записей. И ещё хотел спросить у гуру работающих с Profiler - а там случайно нету возможности узнать если я сделал единичный запрос, сколько времени ушло на работу с индексом, сколько на работу с файлом данных, и сколько на сортировку? (ну или прочитанный объъём в байтах из файла индекса, файла данных, и временно файла для сортировки) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2014, 22:03:26 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
InterSky, ну вы все правильно думаете. некоторые значения косвенно можно узнать по разности счетчиков. dbforge при профилировании подсчитывает эту разность и выводит. Но насчет влияние фрагментации - нет нельзя. Нет таких счетчиков. На мой взгляд, эффект от OPTIMIZE обычно неверно оценивается. Он заключается в кратковременном засасывании содержимого таблицы в кеш ОС. Запросы на некоторое время ускоряются, но потом все равно замедляются. Я бы не стал туда копать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2014, 09:08:23 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
Разве OPTIMIZE не пересоздат таблицу заново выкинув оттуда все пустые блоки, упорядочив и соединив данные? (я правда не знаю - может ли запись внутри файла.MYD делиться на фрагменты, или же она просто "перезаписывается в конец файла" или "в свободный фрагмент необходимого размера внутри" но целиком? Тоесть если у меня есть файл с тремя записями: 1111111111111112222223333333333 и мне надо увеличить запись "2" на несколько байтов, произойдёт дписывание неуместившегося фрагмента в конец: 111111111111111 222222 3333333333 222 или переписывание целиком? 111111111111111 .......... 3333333333 222222222 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2014, 12:43:47 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
InterSky, ЕМНИП целиком ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2014, 12:47:19 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
InterSkyТоесть если у меня есть файл с тремя записями: 1111111111111112222223333333333 и мне надо увеличить запись "2" на несколько байтов, произойдёт дписывание неуместившегося фрагмента в конец: 111111111111111 222222 3333333333 222 или переписывание целиком? 111111111111111 .......... 3333333333 222222222 Насколько я в курсе, целиком. Нигде не встречал упоминания, что MySQL умеет делить записи на фрагменты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2014, 13:08:11 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
InterSky, и что значит "Разве" ? высказанного мной это не отменяет. "на глазок" нефрагментированная база на 10гб тормозит примерно так же как и фрагментированная на 12гб. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2014, 19:19:19 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
Покажите план Код: sql 1. А не Код: sql 1. И поймем все сразу... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2014, 20:04:05 |
|
||
|
|

start [/forum/topic.php?all=1&fid=47&tid=1834757]: |
0ms |
get settings: |
6ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
59ms |
get topic data: |
6ms |
get forum data: |
1ms |
get page messages: |
39ms |
get tp. blocked users: |
1ms |
| others: | 200ms |
| total: | 326ms |

| 0 / 0 |
