Назрела необходимость оптимайзить базу. Основной запрос занимает секунд 15
В базе ~ 220к записей (140к в 1 таблице , 70к в другой)
На ВДСке 128МБ памяти всего, 40МБ Active, остальное либо inactive wired buf и т.п.
Когда mysqld работает всю свободную память съедает.
Впринципе рассматриваю вариант с переходом на тариф с 256 мб.
Ключи какие можно было создал (по которым джоин идет). Основное время (по запросу) занимает сортировка (ORDER by price) без него выполняется не дольше 0.001 секунды. Какие параметры лучше потюнить?
Увеличивал key_buffer join_buffer и sort buffer - почти никакого эффекта.
базы в сумме занимают мегов 40, но могут вырасти.

Batler, значит не все ключи создал))
 
раз ордер бай прайс так тормозит.
 
попробуй избавиться от filesort в explain

http://habrahabr.ru/blogs/mysql/70435/
http://highload.com.ua/index.php/tag/mysql/

Batler

Основное время (по запросу) занимает сортировка (ORDER by price) без него выполняется не дольше 0.001 секунды. Какие параметры лучше потюнить?

1. Попробуй содать еще поле negativeprice, где хранить цену с отрицательным значением, индексы по обоим полям и сортировка только ASC.
2. Тебе реально надо все 240K сортировать по цене? Наверняка есть какие-то ограничения, например сортировать только товары в рубрике тогда AND rubid=6 c индексом по rubid сократит время запроса во столько раз, сколько у тебя рубрик.
Это кстати совет всем, если вам надо показать три последние новости никогда не делайте ORDER BY time по всей таблице, наложите ограничение по времени - например выбираем только за последний месяц.
3. Самый ценный совет - открой для себе команду EXPLAIN

AlexB

если вам надо показать три последние новости никогда не делайте ORDER BY time по всей таблице, наложите ограничение по времени - например выбираем только за последний месяц.

это оч круто, кстати, еще когда ты мне сказал, я сразу сделал и охуел)

мускуль легко оптимизировать. помню както правильно поставленный лимит обогатил мну на 150 баксов ...
 
ибо у парней выборка выполнялась 40 секунд (контекстная реклама, 600млн строк + жойнилось несколько таблиц по 100к), после моих маленьких манипуляций стал выполняться 0.005 секунды ... :)))))

phpdude, вместо лимита заюзал "where id > 0 and id < 30", что-то типа того?

adw0rd, нет, просто сортировал только нужные данные, а не 600млн строк )))
 
писать запросы по учебникам + 6ая нормализация УГ в мускуле)

AlexB, В самом общем случае желательно сортировать без дополнительных параметров.
Потом появляются некоторые условия. В любом случае выборка ограничена 20 строками (LIMIT 20)
 
Запрос с джоином, и как показал EXPLAIN он пытался сортировать базу которая джойнится к основной (порядка 20к записей) причем в файле. И говорил что создает временную таблицу.
 
Добавил 13 символов в запрос => время сократилось с 17.59 секунд до 0.05 секунд. =)
Исчезли всякие временные таблицы и filesort =)
Всем спасибо. phpdude, про учебники абсолютно согласен, равно как и про нормализацию.
 
Пример: в справочной литературе пишут, что чтобы выбрать одну случайную запись надо писать так:
SELECT * FROM tbl ORDER BY RAND() LIMIT 1

SELECT * FROM tbl ORDER BY RAND() LIMIT 1

я помянул твой сервер ...

6ая нормализация УГ

ебанирот
 
нет вот єто ебанирот

Batler

AlexB, В самом общем случае желательно сортировать без дополнительных параметров.
Потом появляются некоторые условия. В любом случае выборка ограничена 20 строками (LIMIT 20)

Я это делаю так
 
select @id:=id from news Order by DateTimeDESC limit 200000,1;
select * from news where id>@id Order by DateTimeDESC limit 20;
 
вместо
 
select * from news Order by DateTimeDESC limit 200000,20;

AlexB, ты правильно делаешь :)

Я тупой =)
поясните в чем принципиальное отличие от запроса все в одном?
Я бы просто ключ добавил к полю DateTimeDESC

Вообще-то это некоторая magic. mysql плохо умеет использовать индекс для сортироки.
Видимо тут какое-то шаманство, во всяком в первом случае он вообще не обращается в таблицу, а все берет из индекса, а во втором индекс игнорирует для больших значений limit. В общем, глянь планы запросов - увидишь.
 
using index - в первом
using filesort - во втором (force index улучшает ситуацию незначительно)