metaclass: (Default)
[personal profile] metaclass
Использование MySQL как NoSQL

Они там в начале профилируют выполнение поиска по первичному ключу в MySQL (в противовес летающему memcached) и у меня мозг споткнулся на следующей фразе:
MYSQLparse() и MYSQLlex() были вызваны в процессе разбора SQL запроса. make_join_statistics() и JOIN::optimize() были вызваны в фазе оптимизации запроса. Это и есть "SQL-оверхед".

Это, простите, как? Запрос для поиска по первичному ключу парсится и препарится каждый раз заново, использовать подготовленные заранее запросы невозможно или авторы этого не знают?

Date: 2010-12-16 07:56 am (UTC)
From: [identity profile] plumqqz.livejournal.com
Это, простите, как? Запрос для поиска по первичному ключу парсится и препарится каждый раз заново, использовать подготовленные заранее запросы невозможно или авторы этого не знают?

Similis simili gaudet, не понимаю, что Вас удивляет.

Date: 2010-12-16 08:41 am (UTC)
From: [identity profile] molnij.livejournal.com
Если запускается с параллельных потоков в разных сессиях, то не факт, что удастся использовать. Собственно они и сделали в результате промежуточный слой, который держал соединение и позволял использовать один и тот же разобранный запрос.

Date: 2010-12-16 08:54 am (UTC)
From: [identity profile] metaclass.livejournal.com
Ага, как их промежуточный слой работает с транзакциями и ссылочной целостностью, вопрос совершенно отдельный.
И даже с параллельных потоков - лучше 100 одинаковых отпрепаренных запросов на 100 потоков, выполняющиеся по 1000 раз в секунду, чем 100000 раз парсить и выполнять запросы.

Date: 2010-12-16 09:18 am (UTC)
From: [identity profile] molnij.livejournal.com
Ну разумеется отдельный :) Хотя, когда встает вопрос о выжимании последних соков, иногда и на грязное чтение как-то подзабивают (впрочем, уже от задачи зависит).
Естественно, что лучше 100 отпрепаренных запросов. Но это вопрос к конкретному приложению. Рассматриваемый пример несколько искусственен. Не знаю тонкостей мускула и использованных тулз, но могу предположить, что после второго запроса там уже все из кеша бралось по факту, так что измерялась очень вакуумно-сферическая величина, в которой естественно первое место занял парс.

Date: 2010-12-16 09:27 am (UTC)
From: [identity profile] gds.livejournal.com
раньше mysql не умел prepared statements. Клиент склеивал sql, слал на сервер, так всё и работало. Интересно, это уже поправили, или как раз это связано с обсуждаемой проблемой?

Date: 2010-12-16 08:31 pm (UTC)
From: [identity profile] basanov.livejournal.com
Кстати да. Не знал, что Мускуль умеет препарить стейтменты. =) Помнится действительно клеил и вообще.

Profile

metaclass: (Default)
metaclass

April 2017

S M T W T F S
      1
2345678
9101112 131415
16171819202122
23242526272829
30      

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Oct. 17th, 2025 05:09 am
Powered by Dreamwidth Studios