У меня установлен денвер, но не это важно, запускаю 1 скрипт по кругу, который делает запросы к MySQL постоянно.
Скрипт следующего характера:
Запрос к таблице№1. Получить 1000 записей.
Запрос №2 (выполняется 1000 раз), получить 1000 результатов.
В случаях, где запрос не вернул записи (это 900 результатов из 1000) - удалить подобные записи.
Индексы стоят только по полям, которым делается SELECT + DELETE. Итого должно работать максимально быстро, но быстрой работы не вижу. Возможно для чтения таблиц необходимо выделить больше ресурсов, или под индексы. Итак, если я смотрю Диспечер Задач Windows - вижу 10-12% нагрузки ЦП, памяти 200мб, не больше.
Теперь скорость выполнения всех операций по прогнозам - 15-16 дней, не подходит. Вопрос:
Какие именно настройки стоит изменить, чтобы позволить MySQL + Apache + PHP (1 клиент, 1 скрипт) выполнять его намного быстрее? Можно ли всё это ускорить с учётом, что компьютер стоит свободный без другой нагрузки, то есть максимально всё отправить в обработку данных скриптов.
То есть можно ли настроить работу быстрее, и какие параметры стоит трогать?
Компьютер: 8гб ОЗУ, 3.3 GHz Intel Core i5-2500k. Движок таблиц: InnoDB.
П.С. В Базе Данных существуют и другие таблицы, может их стоит удалить, чтобы на них ресурсы не выделялись (под кеш, индексы и т.д.?)
_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
Полная Версия: Все ресурсы отдать под PHP+MySQL
| Цитата (inpost @ 16.06.2013 - 18:23) |
| П.С. В Базе Данных существуют и другие таблицы, может их стоит удалить, чтобы на них ресурсы не выделялись (под кеш, индексы и т.д.?) |
таблицы, и индексы тоже, хранятся в файлах, так что проблем нет с этим.
| Цитата (inpost @ 16.06.2013 - 18:23) |
| Запрос к таблице№1. Получить 1000 записей. Запрос №2 (выполняется 1000 раз), получить 1000 результатов. В случаях, где запрос не вернул записи (это 900 результатов из 1000) - удалить подобные записи. |
Что-то мне подсказывает, что это можно сделать одним запросом. Что значит "получить результат"?
| Цитата |
| Получить 1000 записей<...> выполняется 1000 раз, получить 1000 результатов |
выборка обходится дороже, надо сокращать количество запросов
| Цитата (rooor @ 16.06.2013 - 18:49) |
| выборка обходится дороже, надо сокращать количество запросов |
выбирать по 10000?
| Цитата (inpost @ 16.06.2013 - 22:23) |
| Скрипт следующего характера: Запрос к таблице№1. Получить 1000 записей. Запрос №2 (выполняется 1000 раз), получить 1000 результатов. В случаях, где запрос не вернул записи (это 900 результатов из 1000) - удалить подобные записи. |
Я бы по-другому сделал.
- Выбрать нужные записи, тут же записать во временную таблицу (без индексков).
- По окончании всех выборок сделать индексы для временной таблицы.
- Поменять местами временную и основную таблицы.
И сделать это всё средствами Мускуля, не привлекая ПХП.
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
| Цитата (sergeiss @ 16.06.2013 - 19:00) | ||
Я бы по-другому сделал. - Выбрать нужные записи, тут же записать во временную таблицу (без индексков). - По окончании всех выборок сделать индексы для временной таблицы. - Поменять местами временную и основную таблицы. И сделать это всё средствами Мускуля, не привлекая ПХП. |
Я вот не понимаю, а чего одним дилитом никто не думал, что это возможно? Ну а касательно "только мускулем" - это верно бесспорно. На тот случай, если нужно больше одного запроса
| Цитата (glock18 @ 16.06.2013 - 22:53) | ||
выбирать по 10000? |
да хоть по 20))
если можно сделать одним запросом, зачем делать 1000?
я не знаю конечной цели, это лишь пример) и моё предположение)
уверен, что Инпост уже перепробовал разные варианты, но вдруг чего пропустил)
| Цитата (rooor @ 16.06.2013 - 19:08) |
| да хоть по 20)) |
тогда запросов будет в ~50 раз больше, чем сейчас
| Цитата (glock18 @ 16.06.2013 - 23:07) |
| Я вот не понимаю, а чего одним дилитом никто не думал, что это возможно? |
По моему опыту... Для больших таблиц зачастую проще (быстрее) сделать так, как я описал - когда реально много удаляем. Когда количество удаляемых данных соизмеримо с количеством остающихся данных. Потому что еще и индексы переделываются, на что время уходит тоже.
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
| Цитата (sergeiss @ 16.06.2013 - 19:09) |
| По моему опыту... Для больших таблиц зачастую проще (быстрее) сделать так, как я описал - когда реально много удаляем. Когда количество удаляемых данных соизмеримо с количеством остающихся данных. Потому что еще и индексы переделываются, на что время уходит тоже. |
В целом логично, но индекс ведь перестраиваться будет после выполнения всего запроса, не? Один запрос - одна реиндексация. Хотя в целом идея, конечно, хорошая, но здесь delete и optimize сделают все, мне кажется, шелково
| Цитата (inpost @ 16.06.2013 - 18:23) |
| Индексы стоят только по полям, которым делается SELECT + DELETE. Итого должно работать максимально быстро, но быстрой работы не вижу. |
Смотря как построен запрос. Наличие индекса и присутствие в критерии выборки только полей с индексами еще не значит, что будут задействованы индексы.
К тому же если индекс слишком большой, может сделать его с меньшей селективностью.
_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
| Цитата (T1grOK @ 17.06.2013 - 08:48) | ||
Смотря как построен запрос. Наличие индекса и присутствие в критерии выборки только полей с индексами еще не значит, что будут задействованы индексы. К тому же если индекс слишком большой, может сделать его с меньшей селективностью. |
*nod*
Вообще говоря надо по explain смотреть план выполнения запроса, чтобы утверждать, что он "должен работать максимально быстро". Как бы то ни было, решение вполне вероятно возможно одним запросом
Здесь расположена полная версия этой страницы.