Меню
Что нового?

Скорость работы MySql

  • Автор темы Автор темы Maxxon
  • Дата начала Дата начала
Maxxon
ну и чего такого в статистике имеется, что не укладывается в сумму, среднее арифметическое и минимум/максимум? какие возможности именно пхп используются, что нельзя это сделать в SQL ?
 
[offtop]Бойся телепатов :) Они уже трудятся над раскрытием твоей конфиденциальной информации...[/offtop]
 
Потому что я грешу на настройки MySql, что памяти 256 метров на сервере, и ей наверняка можно выделить побольше, чем в данный момент настроено, чтобы соображала быстрее.
Именно на этот вопрос мне бы хотелось получить ответ.
Как, где, и будет ли прирост в скорости.
my.cnf или какие-то другие конфигурационные файлы в linux?

Если MySql по дефолту работает с памятью меньше мегабайта, судя по настройкам? Я поставил 16 метров и прироста не заметил. Неужели здесь поможет только нагрузка арифметикой самой базы? Желания переписывать весь скрипт пока нету :( ...
 
Именно на этот вопрос мне бы хотелось получить ответ.
Нажмите для раскрытия...
нет проблем.
читай, настраивай.

тебе нужна подсказка, где почитать, или ты даже этого самостоятельно не сообразишь?
 
Фанат
Самостоятельно я нашел faq по "тонкой настройке" mysql, но он мало помог в результате. Ты мне скажи точно, это реально даст прирост в скорости или нет? Или мне настраивать себя на переписывание скрипта заново?

Сорри, за тупые вопросы :)
 
по дефолту работает с памятью меньше мегабайта
т.е. не компе с 1мб оперативки?

Я поставил 16 метров и прироста не заметил
где чего поставил?

ты же заставляешь mysql вывалить тебе всю базу в скрипт, но хочешь быстрее
 
ТОЧНО
ТЕБЕ
НИКТО
НЕ СКАЖЕТ

потому что никто не знает, ЧТО у тебя тормозит, и тормозит ли ВООБЩЕ

короче, надо заканчивать это плодотворную дискуссию.
 
Дык чтож с ним сделать-то? :(
Кто сможет дать конкретный ответ что делать с настройками?

-~{}~ 01.03.06 15:38:

Ок. Заканчиваем.
 
возьми все запросы, которые у тебя выполняются в твоём скрипте
(я ОЧЕНЬ надеюсь, что у тебя там нет запросов в цикле)

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

я доступно расписал алгоритм?
 
Или просто засеки время до резалта и после резалта и сложи его всё... А лучше выведи еще весь список своих квэрей...

У меня это имеет след вид:
0.030209064483643 select .......... 0.00071310997009277
0.039928197860718 select .......... 0.00097513198852539
0.040824174880981 select............0.00023484230041504
0.041381120681763 select............0.00020313262939453

и в конце еще выведи общее время выполнения скрипта....
 
Резюмируя вышесказанное подчеркну то, что говорят здесь умные люди: :-)

1. Необходимо определить место в твоем комплексе, где работа действительно "тормозит". Советую просто прогнать скрипт в дебагере. При 10 минутной задержке ты точно увидишь где то самое узкое место.
Скорее всего тормозит именно обработка PHP, в противном случае неправильно спроектирована структура БД

2. Не делать вещей типа... выборка всех строк и сохранение их в массив, а потом обработка в PHP - он не приспособлен к ворочанию больших объемов данных (в том числе и чисел) - для этого и нужен сервер БД

3. Как можно больше операций засунуть в SQL-запрос
4. Минимизировать кол-во строк/столбцов в ответе SQL - для того чтобы снизить нагрузку на канал между Apache и MySQL - как тебе известно это IPC(сокеты или каналы), передача больших массивов данных через них плохо сказывается на произвидительности

Все остальное, конечно, надо смотреть...
Удачи! :-)

3
 
Автор оригинала: Сергей Тарасов
2. Не делать вещей типа... выборка всех строк и сохранение их в массив, а потом обработка в PHP - он не приспособлен к ворочанию больших объемов данных (в том числе и чисел) - для этого и нужен сервер БД

3. Как можно больше операций засунуть в SQL-запрос
Нажмите для раскрытия...
А вот позволю себе с этим не согласиться ;)
При больших нагрузках бывает гораздо выгоднее перенести все вычисления в php, чтобы уменьшить нагрузку на базу. Думаю, товарищи из мамбы меня поддержат :)
 
Хм... Это извечная, я бы сказал, дискуссия... :-)

По поводу нагрузок - что в лоб что по лбу... :-) Либо мы нагружаем Apache либо MySQL. И то и другое - процессы системы.

Могу привести аргументы в защиту своих утверждений... Дело в том, что для обработки больших массивов данных в СУБД применяются СПЕЦИАЛЬНЫЕ алгоритмы и СПЕЦИАЛЬНЫЕ методы хранения данных, над которыми бьются лучшие умы... PHP-скрипты пользователей обычно этим не отличаются... :-)
 
ой, только не надо мне объяснять ;)
И причем здесь апач? ;)
Возьмем оффлайновый скрипт. Селект по InnoDB'шной таблице, в которой 100-200 миллионов записей такого типа id | ts. Цель - сгруппировать данные по ts и положить в другое место:
select count(*), ts from table group by ts
за приемлемое время не выполнится. Лимиты не помогут. А вот последовательные
select id, ts from table limit 0,50000
с группировкой php-скриптом - отлично отработается.

А лучшие умы не могут предусмотреть всего, тем более, что мы вроде тоже не идиоты ;)
 
Весь вопрос заключается только в том, насколько ты владеешь SQL и насколько правильно спроектирована БД
 
MadMike
я не верю в то, что ты сказал, подтверди свои высказывания тестами и результатами профилирования.
 
Итак у тебя 200 млн записей
Тогда представь сколько памяти и времени у тебя сожрет 4000 таких запросов???
select id, ts from table limit 0,50000
С master_x полностью согласен.
 
master_x
Сергей Тарасов

господа, тут не в "верю , не верю" играют.
если вам интересно попробуйте протестите.
 
moxnatiy
хорошая позиция.
писать всякий бред, а если кому-то не нравится, то пусть сам тестирует.
 
Войдите или зарегистрируйтесь для ответа.
Сверху