Здравствуйте!
Какие существуют способы физически отсортировать записи в таблице MySQL?
Можно ли это сделать с из PHP скрипта?
сделай дамп в нужном порядке а затем вставь.
>сделай дамп в нужном порядке а затем вставь.А зачем их физически сортировать???
>>сделай дамп в нужном порядке а затем вставь.
>
>А зачем их физически сортировать???Что значит физически отсортировать базы??????????
Совершенно безразлично как они там лежат, mysql тебе их отдаст так как тебе надо, вплоть до того, что сама соберет данные из разных таблиц в один запрос, из чего потом можно сделать 1 массив....
а на физическом уровне MySQL лучше не лазить....... эт тебе не текстовый файл
>>>сделай дамп в нужном порядке а затем вставь.
>>
>>А зачем их физически сортировать???Для скорости. Подобная вещь может повысить скорость выполнения запросов. На больших базах это помогает.
>Что значит физически отсортировать базы??????????
>Совершенно безразлично как они там лежат, mysql тебе их отдаст так как
>тебе надо, вплоть до того, что сама соберет данные из разных
>таблиц в один запрос, из чего потом можно сделать 1 массив....Да, но скорость, скорость... Покрути-ка гиговые таблички - никакой кеш не спасет.
>а на физическом уровне MySQL лучше не лазить....... эт тебе не текстовый
>файлНу не кто же не предлагает править вручную файлы БД.
>>>>сделай дамп в нужном порядке а затем вставь.
>>>
>>>А зачем их физически сортировать???
>
>Для скорости. Подобная вещь может повысить скорость выполнения запросов. На больших базах
>это помогает.
>
>>Что значит физически отсортировать базы??????????
>>Совершенно безразлично как они там лежат, mysql тебе их отдаст так как
>>тебе надо, вплоть до того, что сама соберет данные из разных
>>таблиц в один запрос, из чего потом можно сделать 1 массив....
>
>Да, но скорость, скорость... Покрути-ка гиговые таблички - никакой кеш не спасет.
>
>
>>а на физическом уровне MySQL лучше не лазить....... эт тебе не текстовый
>>файл
>
>Ну не кто же не предлагает править вручную файлы БД.
а индексирование типа нельзя использовать? :)
Могу показать пример базы, весящей 790 мегов, из 8 000 000 наименований, запрос обрабатывает за 0,02 секунды, на Целероне 1100...... без напрягов, поиск по каталогу запчастей......... надо?
Кстати, а что за база запчастей? Не продается ли? Один мой клиент очень ищет себе.
>а индексирование типа нельзя использовать? :)Естественно надо использовать. Но при упорядоченном хранении определенные запросы работают гораздо быстрее. Только из-за того, что не требуется по многу раз дергать файл.
>>а индексирование типа нельзя использовать? :)
>
>Естественно надо использовать. Но при упорядоченном хранении определенные запросы работают гораздо быстрее.
>Только из-за того, что не требуется по многу раз дергать файл.Эту задачу и решают индексы.
Тебе же, для ускорения работы, нужно скорее грамотно изменить сами таблицы. Например, если все таблицы будут состоять из столбцов CHAR(200) и не будет ни одного VARCHAR, то скорость работы резко возрастёт. Просто по логике - если у нас каждая запись фиксированной длины, мы может перемещаться по файлу смещением.
А вообще почитай документацию по оптимизации MySQL - есть достаточно много тонкостей и способов выжать самую большую скорость по сравнению со всеми существующими на данным момент базами. Как же именно база работает со своими файлами, тебя особо интересовать не должно. Если ты, конечно, не её администратор. Если админ - читай ту же документацию по MySQL.
Удачи :)
По поводу базы пусть на мыло пишет, можем помочь, тока обновлять ее он так запарится....... зачастую там прайс производителя надо обновлять целиком, а это как минимум файл мега в 3 ...........
>>>а индексирование типа нельзя использовать? :)
>>
>>Естественно надо использовать. Но при упорядоченном хранении определенные запросы работают гораздо быстрее.
>>Только из-за того, что не требуется по многу раз дергать файл.
>
>Эту задачу и решают индексы.Индексы решают проблему выбора нужных записей, и оптимизируют поиск этих записей. Это разные уровни. Одно дело определить где находится требуемая запись, а другое - вытащить ее.
Вот пример такой - большая база, проиндексирована естественно. На ней активно идет изменение. Через месяц-другой она начинает тормозить. Причем торможение становится больше и больше. И в этой ситуации спасал дамп и восстановление. Если вы с такой ситуацией не сталкивались, то вам пока просто повезло :)
МуSQL вобще довольно плохо работает с изменяемыми б/д, по крайней мере производительность по вставкам у нее наихудшаяя (суда по тестам, которых в инете навалом). В частности в той задаче от MySQL отказались в пользу postgres.
>>>>а индексирование типа нельзя использовать? :)
>>>
>>>Естественно надо использовать. Но при упорядоченном хранении определенные запросы работают гораздо быстрее.
>>>Только из-за того, что не требуется по многу раз дергать файл.
>>
>>Эту задачу и решают индексы.
>
>Индексы решают проблему выбора нужных записей, и оптимизируют поиск этих записей.
>Это разные уровни. Одно дело определить где находится требуемая запись, а
>другое - вытащить ее.
>
>Вот пример такой - большая база, проиндексирована естественно. На ней активно идетИменно для динамического вормата полей и существует optimize table, который помимо прочего дефрагментирует файл БД и сортирует индексные страницы.
>изменение. Через месяц-другой она начинает тормозить. Причем торможение становится больше и
>больше. И в этой ситуации спасал дамп и восстановление. Если вы
>с такой ситуацией не сталкивались, то вам пока просто повезло :)
>
>
>МуSQL вобще довольно плохо работает с изменяемыми б/д, по крайней мере производительность
>по вставкам у нее наихудшаяя (суда по тестам, которых в инете
>навалом). В частности в той задаче от MySQL отказались в пользу
>postgres.
>>Вот пример такой - большая база, проиндексирована естественно. На ней активно идет
>
>Именно для динамического вормата полей и существует optimize table, который помимо прочего
>дефрагментирует файл БД и сортирует индексные страницы.
>>изменение. Через месяц-другой она начинает тормозить. Причем торможение становится больше и
>>больше. И в этой ситуации спасал дамп и восстановление. Если вы
>>с такой ситуацией не сталкивались, то вам пока просто повезло :)
>>
Это на какой ОСи крутилось?????????? Что бзнать на всякий случай..... а то мало-ли,............
>Индексы решают проблему выбора нужных записей, и оптимизируют поиск этих записей.
>Это разные уровни. Одно дело определить где находится требуемая запись, а >другое - вытащить ее.А в чём проблема с вытаскиванием? Это уже проблема файловой системы в таком случае.
>Вот пример такой - большая база, проиндексирована естественно. На ней активно идет
>изменение. Через месяц-другой она начинает тормозить. Причем торможение становится больше и
>больше. И в этой ситуации спасал дамп и восстановление. Если вы
>с такой ситуацией не сталкивались, то вам пока просто повезло :)А переиндексировать таблицы не пробовали? :)
Сколько тысяч записей, если не секрет? У меня таблицы на 20-30 тысяч работают без особых проблем. Если речь идёт о миллионах записей - тогда да, тут уже не до скорости.Вообще индексы - это не всегда панацея и очень тонкая вещь. Нужно просто понимать что они делают и как работают.
>МуSQL вобще довольно плохо работает с изменяемыми б/д, по крайней мере производительность
>по вставкам у нее наихудшаяя (суда по тестам, которых в инете
>навалом). В частности в той задаче от MySQL отказались в пользу
>postgres.Тут нужно просто уметь использовать возможности. Индексация и время добавления - вещи обратнопропорциональные. Когда требуется перегонять большие данные - удали индексы. А после создай заново. Иначе для каждой записи будет проводиться сопоставление индекса и т.д. (если же ещё и куча этих индексов - вообще беда). Индексы же позволяют резко увеличить скорость именно при чтении, что зачастую бывает гораздо важнее. Очень часто меняющиеся данные - откажись от индексации. В чтении потеряешь, зато при добавлении выиграешь. Ещё есть такие вещи, как LOAD DATA - это эффективнее оператора INSERT, так как загружает данные в массе.
И не уверен, что MySQL проиграет по тестам, если будет работать с оптимально реализованными таблицами. Хотя спорить не буду, не проверял. Просто пока действительно не сталкивался с задачами, которые не мог решить бы MySQL.
>>Индексы решают проблему выбора нужных записей, и оптимизируют поиск этих записей.
>>Это разные уровни. Одно дело определить где находится требуемая запись, а >другое - вытащить ее.
>
>А в чём проблема с вытаскиванием? Это уже проблема файловой системы в
>таком случае.
>
>>Вот пример такой - большая база, проиндексирована естественно. На ней активно идет
>>изменение. Через месяц-другой она начинает тормозить. Причем торможение становится больше и
>>больше. И в этой ситуации спасал дамп и восстановление. Если вы
>>с такой ситуацией не сталкивались, то вам пока просто повезло :)
>
у меня в базе 8 000 000 наименований, кстати я когда обновлял пробовал INSERT IGNORE - тоже шустро работает...... и как-бы косяков не замечено пока, база вертится месяц - полтора, правда обновляли всего 2 раза....
>А переиндексировать таблицы не пробовали? :)
>Сколько тысяч записей, если не секрет? У меня таблицы на 20-30 тысяч
>работают без особых проблем. Если речь идёт о миллионах записей -
>тогда да, тут уже не до скорости.
>
>Вообще индексы - это не всегда панацея и очень тонкая вещь. Нужно
>просто понимать что они делают и как работают.
>
>>МуSQL вобще довольно плохо работает с изменяемыми б/д, по крайней мере производительность
>>по вставкам у нее наихудшаяя (суда по тестам, которых в инете
>>навалом). В частности в той задаче от MySQL отказались в пользу
>>postgres.
>
>Тут нужно просто уметь использовать возможности. Индексация и время добавления - вещи
>обратнопропорциональные. Когда требуется перегонять большие данные - удали индексы. А после
>создай заново. Иначе для каждой записи будет проводиться сопоставление индекса и
>т.д. (если же ещё и куча этих индексов - вообще беда).
>Индексы же позволяют резко увеличить скорость именно при чтении, что зачастую
>бывает гораздо важнее. Очень часто меняющиеся данные - откажись от индексации.
>В чтении потеряешь, зато при добавлении выиграешь. Ещё есть такие вещи,
>как LOAD DATA - это эффективнее оператора INSERT, так как загружает
>данные в массе.
>
>И не уверен, что MySQL проиграет по тестам, если будет работать с
>оптимально реализованными таблицами. Хотя спорить не буду, не проверял. Просто пока
>действительно не сталкивался с задачами, которые не мог решить бы MySQL.
>
Как произвести оптимизацию хранилища в MySQLПочистить "дырки" (дефрагментация), обновить статистику и отсортировать индексы:
OPTIMIZE TABLE имя_таблицы;
или использовать: myisamchk --quick --check-only-changed --sort-index --analyze
Внимание, myisamchk нужно запускать при _не_ запущенном mysqld, иначе нужно использовать утилиту mysqlcheck
(mysqlcheck --repair --analyze --optimize --all-databases --auto-repair)Апдейт статистики оптимизатора:
ANALYZE TABLE имя_таблицы;
или использовать: myisamchk --analyzeРекомендуется регулярно выполнять:
isamchk -r --silent --sort-index -O sort_buffer_size=16M db_dir/*.ISM
myisamchk -r --silent --sort-index -O sort_buffer_size=16M db_dir/*.MYI
При сортировке записей можно использовать ORDER BY? много недостатков он имеет если база данных небольшая (1000 строк)?
Ещё подскажите пожалуйста что такое "дамп"?
>При сортировке записей можно использовать ORDER BY? много недостатков он имеет если
>база данных небольшая (1000 строк)?
>Ещё подскажите пожалуйста что такое "дамп"?Дамп грубо говоря преобразование БД в sql запросы, например для резервного копирования (смотри утилиту mysqldump все сразу станет понятно).
Поскольку альтернативы ORDER BY нету то вопрос довольно забавный :)
Проиндексируй и используй ORDER BY. Для такой базы даже не стоит думать об оптимизации :)
Спасибо всем за помощь!