ФорумРазработкаБазы данных → MySQL стала раком =)

MySQL стала раком =)

  • Batler

    Сообщения: 142 Репутация: N Группа: Кто попало

    Spritz 27 октября 2009 г. 20:49

    Назрела необходимость оптимайзить базу. Основной запрос занимает секунд 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, но могут вырасти.
  • phpdude

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz 27 октября 2009 г. 21:00, спустя 11 минут 1 секунду

    Batler, значит не все ключи создал))

    раз ордер бай прайс так тормозит.

    попробуй избавиться от filesort в explain
    Сапожник без сапог
  • adw0rd

    Сообщения: 22959 Репутация: N Группа: в ухо

    Spritz 27 октября 2009 г. 21:30, спустя 30 минут 24 секунды

    http://habrahabr.ru/blogs/mysql/70435/
    http://highload.com.ua/index.php/tag/mysql/
    https://smappi.org/ - платформа по созданию API на все случаи жизни
  • AlexB

    Сообщения: 4306 Репутация: N Группа: в ухо

    Spritz 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
  • md5

    Сообщения: 11960 Репутация: N Группа: в ухо

    Spritz 28 октября 2009 г. 12:43, спустя 4 минуты 25 секунд


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

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz 28 октября 2009 г. 13:08, спустя 24 минуты 32 секунды

    мускуль легко оптимизировать. помню както правильно поставленный лимит обогатил мну на 150 баксов …

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

    Сообщения: 22959 Репутация: N Группа: в ухо

    Spritz 28 октября 2009 г. 13:11, спустя 3 минуты 21 секунду

    phpdude, вместо лимита заюзал "where id > 0 and id < 30", что-то типа того?
    https://smappi.org/ - платформа по созданию API на все случаи жизни
  • phpdude

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz 28 октября 2009 г. 13:40, спустя 28 минут 31 секунду

    adw0rd, нет, просто сортировал только нужные данные, а не 600млн строк )))

    писать запросы по учебникам + 6ая нормализация УГ в мускуле)
    Сапожник без сапог
  • Batler

    Сообщения: 142 Репутация: N Группа: Кто попало

    Spritz 28 октября 2009 г. 16: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
  • phpdude

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz 28 октября 2009 г. 17:15, спустя 40 минут 30 секунд

    SELECT * FROM tbl ORDER BY RAND() LIMIT 1


    я помянул твой сервер …
    Сапожник без сапог
  • Trej Gun

    Сообщения: 5305 Репутация: N Группа: в ухо

    Spritz 28 октября 2009 г. 17:49, спустя 34 минуты 6 секунд

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

    ебанирот

    SELECT * FROM tbl ORDER BY RAND() LIMIT 1

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

    Сообщения: 4306 Репутация: N Группа: в ухо

    Spritz 28 октября 2009 г. 18: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;
  • phpdude

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz 28 октября 2009 г. 19:32, спустя 1 час 20 минут 33 секунды

    AlexB, ты правильно делаешь :)
    Сапожник без сапог
  • Batler

    Сообщения: 142 Репутация: N Группа: Кто попало

    Spritz 29 октября 2009 г. 5:54, спустя 10 часов 21 минуту 56 секунд

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

    Сообщения: 4306 Репутация: N Группа: в ухо

    Spritz 29 октября 2009 г. 11:15, спустя 5 часов 21 минуту 24 секунды

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

    using index - в первом
    using filesort - во втором (force index улучшает ситуацию незначительно)

Пожалуйста, авторизуйтесь, чтобы написать комментарий!