Назрела необходимость оптимайзить базу. Основной запрос занимает секунд 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, но могут вырасти.
новые сообщения
ответы на мои сообщения
избранное
скрытые темы
случайный топик
ёбнуть всё в новых вкладках
Форум → Разработка → Базы данных → MySQL стала раком =)
MySQL стала раком =)
Страницы: ← Следующая страница →
-
Сообщения:
142
Репутация:
N
Группа:
Кто попало
-
Сообщения:
26646
Репутация:
N
Группа:
в ухо
Окт. 27, 2009, 9 п.п., спустя 11 минут 1 секунду
Batler, значит не все ключи создал))
раз ордер бай прайс так тормозит.
попробуй избавиться от filesort в explainСапожник без сапог -
Сообщения:
22959
Репутация:
N
Группа:
в ухо
Окт. 27, 2009, 9:30 п.п., спустя 30 минут 24 секунды
https://smappi.org/ - платформа по созданию API на все случаи жизни -
Сообщения:
4306
Репутация:
N
Группа:
в ухо
Окт. 28, 2009, 12:39 п.п., спустя 15 часов 8 минут 45 секунд
Основное время (по запросу) занимает сортировка (ORDER by price) без него выполняется не дольше 0.001 секунды. Какие параметры лучше потюнить?
1. Попробуй содать еще поле negativeprice, где хранить цену с отрицательным значением, индексы по обоим полям и сортировка только ASC.
2. Тебе реально надо все 240K сортировать по цене? Наверняка есть какие-то ограничения, например сортировать только товары в рубрике тогда AND rubid=6 c индексом по rubid сократит время запроса во столько раз, сколько у тебя рубрик.
Это кстати совет всем, если вам надо показать три последние новости никогда не делайте ORDER BY time по всей таблице, наложите ограничение по времени - например выбираем только за последний месяц.
3. Самый ценный совет - открой для себе команду EXPLAIN -
Сообщения:
11960
Репутация:
N
Группа:
в ухо
Окт. 28, 2009, 12:43 п.п., спустя 4 минуты 25 секунд
это оч круто, кстати, еще когда ты мне сказал, я сразу сделал и охуел)
если вам надо показать три последние новости никогда не делайте ORDER BY time по всей таблице, наложите ограничение по времени - например выбираем только за последний месяц.все умрут, а я изумруд -
Сообщения:
26646
Репутация:
N
Группа:
в ухо
Окт. 28, 2009, 1:08 п.п., спустя 24 минуты 32 секунды
мускуль легко оптимизировать. помню както правильно поставленный лимит обогатил мну на 150 баксов …
ибо у парней выборка выполнялась 40 секунд (контекстная реклама, 600млн строк + жойнилось несколько таблиц по 100к), после моих маленьких манипуляций стал выполняться 0.005 секунды … :)))))Сапожник без сапог -
Сообщения:
22959
Репутация:
N
Группа:
в ухо
Окт. 28, 2009, 1:11 п.п., спустя 3 минуты 21 секунду
phpdude, вместо лимита заюзал "where id > 0 and id < 30", что-то типа того?https://smappi.org/ - платформа по созданию API на все случаи жизни
-
Сообщения:
26646
Репутация:
N
Группа:
в ухо
Окт. 28, 2009, 1:40 п.п., спустя 28 минут 31 секунду
adw0rd, нет, просто сортировал только нужные данные, а не 600млн строк )))
писать запросы по учебникам + 6ая нормализация УГ в мускуле)Сапожник без сапог -
Сообщения:
142
Репутация:
N
Группа:
Кто попало
Окт. 28, 2009, 4:34 п.п., спустя 2 часа 54 минуты 34 секунды
AlexB, В самом общем случае желательно сортировать без дополнительных параметров.
Потом появляются некоторые условия. В любом случае выборка ограничена 20 строками (LIMIT 20)
Запрос с джоином, и как показал EXPLAIN он пытался сортировать базу которая джойнится к основной (порядка 20к записей) причем в файле. И говорил что создает временную таблицу.
Добавил 13 символов в запрос => время сократилось с 17.59 секунд до 0.05 секунд. =)
Исчезли всякие временные таблицы и filesort =)
Всем спасибо.Спустя 119 сек.phpdude, про учебники абсолютно согласен, равно как и про нормализацию.
Пример: в справочной литературе пишут, что чтобы выбрать одну случайную запись надо писать так:
SELECT * FROM tbl ORDER BY RAND() LIMIT 1 -
Сообщения:
26646
Репутация:
N
Группа:
в ухо
Окт. 28, 2009, 5:15 п.п., спустя 40 минут 30 секунд
SELECT * FROM tbl ORDER BY RAND() LIMIT 1
я помянул твой сервер …Сапожник без сапог -
Сообщения:
5305
Репутация:
N
Группа:
в ухо
Окт. 28, 2009, 5:49 п.п., спустя 34 минуты 6 секунд
6ая нормализация УГ
ебаниротSELECT * FROM tbl ORDER BY RAND() LIMIT 1
нет вот єто ебанирот -
Сообщения:
4306
Репутация:
N
Группа:
в ухо
Окт. 28, 2009, 6:12 п.п., спустя 22 минуты 44 секунды
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; -
Сообщения:
26646
Репутация:
N
Группа:
в ухо
Окт. 28, 2009, 7:32 п.п., спустя 1 час 20 минут 33 секунды
AlexB, ты правильно делаешь :)Сапожник без сапог
-
Сообщения:
142
Репутация:
N
Группа:
Кто попало
Окт. 29, 2009, 5:54 д.п., спустя 10 часов 21 минуту 56 секунд
Я тупой =)
поясните в чем принципиальное отличие от запроса все в одном?
Я бы просто ключ добавил к полю DateTimeDESC -
Сообщения:
4306
Репутация:
N
Группа:
в ухо
Окт. 29, 2009, 11:15 д.п., спустя 5 часов 21 минуту 24 секунды
Вообще-то это некоторая magic. mysql плохо умеет использовать индекс для сортироки.
Видимо тут какое-то шаманство, во всяком в первом случае он вообще не обращается в таблицу, а все берет из индекса, а во втором индекс игнорирует для больших значений limit. В общем, глянь планы запросов - увидишь.
using index - в первом
using filesort - во втором (force index улучшает ситуацию незначительно)
Страницы: ← Следующая страница →
Пожалуйста, авторизуйтесь, чтобы написать комментарий!