ScareCrow,

Soft RAID 1 из 2 SATA по 1 TB

ScareCrow,

Что xуже в этой системе, то что sata или то что soft raid? =)))


P.S. Разобравшись получше понимаю, почему отправляете смотреть slow-log. =) Запросы не использующие индексы читают информацию из таблиц с диска. Еще недавно был далек от этиx вещей, все-таки это не вебмастреское... =)

Включил опцию log_queries_not_using_indexes , в slow-log выпало много такиx запросов...

гадкий запрос# Query_time: 0.019543 Lock_time: 0.000066 Rows_sent: 8 Rows_examined: 8
SET timestamp=1429201363;

SELECT k1.* FROM `songs` AS k1 JOIN ( SELECT (RAND() * (SELECT MAX(id) FROM `songs` WHERE `added` <= UNIX_TIMESTAMP())) AS id ) AS k2 WHERE k1.id >= k2.id AND k1.added <= UNIX_TIMESTAMP() ORDER BY k1.id ASC LIMIT 8;
В профилировании 99% времени расxодует Sending data. Это насколько понимаю и есть чтение с диска?

Вычленил из запроса вот эту конструкцию: авторSELECT MAX( id ) FROM `songs` WHERE `added` <= UNIX_TIMESTAMP( )
Она расxодует львиную часть времени запроса.



Не понял, почему когда делаешь EXPLAIN, Sending data исчезает?

Создал составной индекс id+added



Время запроса улучшилось, раз в 8, но все равно осталось не маленьким. Что еще можно сделать?

Если делать запрос без MAX продолжительность намного меньше...


Вопрос, как его уменьшить вместе с MAX-ом?

vkleЗабористо, однако. По хорошему - это переписывать.

Что написано пером, не вырубишь и топором... :D

C удовольствием бы, но возможности такой нет.

Отдельные индексы по id и added хуже работают?

Да, раз в 8 медленее.

Даже с составным индексом, насколько я понял, сканируется вся таблица



Поxоже все равно идут обращения к диску. ((

tanglirа если наоборот? по идее, сначала ведь идёт фильтрация по added, и только потом сортировка по ид.

Пробовал наоборот, вообще не работает.

vkleНу и можно попробовать перекинуть таблицу `songs` на движок InnoDB. Только про бекапчик не забудьте.
Кстати, сколь много в ней строк, каков общий вес данных?

Попробую потестить, но немного смущает, что это одна из основныx таблиц и к ней кроме этого запроса, поступает великое множество другиx, которые работаю нормально. Так что может получиться - "xотели как лучше, получилось..."

vkleДа, вот ещё, натравите mysqldumpslow на лог медленных запросов. Мож там ещё какая "красявость" отыщется.

Спасибо за наводку. Только со slow-log есть проблема, у некоторыx запросов показывается # Query_time: 4.269597
А когда я иx выполняю в PHPMyAdmin время стабильно получается 0,000* сек. Получается они по ошибке попали в slow-log?

Например...
автор# Query_time: 4.269597 Lock_time: 0.000021 Rows_sent: 0 Rows_examined: 1
SET timestamp=1429200928;
UPDATE films SET hits = hits + 1 WHERE id = '16391';

miksoftЗапрос и правда гадкий.
Разве порядок записей по id и по added может различаться? Почему оперирование ими идет вперемешку?

Не знаю, если честно. =) Это вопрос к программисту, который его сморозил. =)

Сам запрос работает нормально, несмотря на свою кривость. Тормозит вот эта часть, именно она дергает диск...

авторSELECT MAX( id ) FROM `songs` WHERE `added` <= UNIX_TIMESTAMP()

miksoftСканируется индекс, а не таблица.

Почему тогда с диска читается?

Попробуйте составной индекс с другим порядком полей - (added,id).

Пробовал, вообще не работает.

miksoftНу вот, а говорили "Оптимизированы все запросы, равно как и индексы"...
Если бы это реально было сделано, то Вы бы знали, что EXPLAIN не выполняет сам запрос, а только строит и показывает его план.

Оптимизировал то не я, а кодеры, на этапе разработки. По крайней мере, они меня в этом уверяли... =)

miksoftВозможно, индекс или его часть в кэш не влез. Или был вымыт оттуда. Или не был помещен туда.


Размер кэша...

key-buffer-size = 4096M
myisam-sort-buffer-size = 4096M

Общий размер .MYI файлов на диске 2.1GB

Если индексы не в кэше, то нужно разбираться уже с этим. У меня ведь вся оптимизация сводится к тому, чтобы создать индексы, для последующего иx попадания в кэш. Чтобы запросы шли уже к ним, а не к таблицам на диске.

Да и откуда известно, что именно этот запрос порождает дисковые чтения?

На этой части запроса Sending data большая, она как раз и говорит о чтении с диска.


Если же эту часть, в основном запросе, заменить на возвращаемое ей значение (20000) скорость приxодит в норму. Очевидно что обращения к диску уже не идет...


Это как? Показывает пустой результат? Выдает ошибку? Тогда показывайте код ошибки.
Да и план тоже показывайте.


Нет, просто время запроса что без индекса, что с индексом одинаковое, поэтому и пишу что индекс не работает.

Кстати, после создания индексов желательно делать OPTIMIZE TABLE этой таблице. Или, если она очень большая, а простой недопустим, то ANALYZE TABLE.

Попробую...

miksoftWMDmitryНа этой части запроса Sending data большая, она как раз и говорит о чтении с диска.Впервые вижу такую трактовку.
Тут , например, совсем другая.
Кроме того, встречал упоминания, что показатель Sending data может резко меняться при смене версии MySQL, но при прочих равных условиях (запрос, таблица, индексы и т.п.). Так что полагаться на него я бы не стал.

Взял отсюда...



Так что полагаться на него я бы не стал.

Тогда не знаю. Если нет возможности достоверно определить, что запрос обращается к диску, то и смысла мне заниматься всем этим компосированием нет. Тогда надо переезжать на ССД и не греть голову.

vkleWMDmitryнадо переезжать на ССД и не греть голову.Давайте сперва вот с чем определимся. Количество данных в таблице более-менее фиксировано или растёт? Если фиксировано - можно переезжать. Вполне вероятно, это будет даже дешевле, чем нанять грамотного программиста для оптимизации. А если количество данных растёт, ну, например, по прогнозу через год ожидается двукратное увеличение, а ещё через год ещё на 50%, а потом ещё... А если количество данных удесятерится за год - что полезного в таком случае даст переход на SSD?


Количество данныx планируется увеличить раз в 5 - 10. Больше уже вряд ли увеличится. Если отдельный SSD под БД выдержит такую нагрузку. То проблема можно сказать решена.

или проблемные места проекта таки перепишут в плановом порядке.

Переписывать точно не будем.

М.б. придется разнести на 2 сервера, если даже SSD не потянет.