Prepare запросов
Dec. 16th, 2010 09:43 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Использование MySQL как NoSQL
Они там в начале профилируют выполнение поиска по первичному ключу в MySQL (в противовес летающему memcached) и у меня мозг споткнулся на следующей фразе:
MYSQLparse() и MYSQLlex() были вызваны в процессе разбора SQL запроса. make_join_statistics() и JOIN::optimize() были вызваны в фазе оптимизации запроса. Это и есть "SQL-оверхед".
Это, простите, как? Запрос для поиска по первичному ключу парсится и препарится каждый раз заново, использовать подготовленные заранее запросы невозможно или авторы этого не знают?
Они там в начале профилируют выполнение поиска по первичному ключу в MySQL (в противовес летающему memcached) и у меня мозг споткнулся на следующей фразе:
MYSQLparse() и MYSQLlex() были вызваны в процессе разбора SQL запроса. make_join_statistics() и JOIN::optimize() были вызваны в фазе оптимизации запроса. Это и есть "SQL-оверхед".
Это, простите, как? Запрос для поиска по первичному ключу парсится и препарится каждый раз заново, использовать подготовленные заранее запросы невозможно или авторы этого не знают?
no subject
Date: 2010-12-16 07:56 am (UTC)Similis simili gaudet, не понимаю, что Вас удивляет.
no subject
Date: 2010-12-16 08:41 am (UTC)no subject
Date: 2010-12-16 08:54 am (UTC)И даже с параллельных потоков - лучше 100 одинаковых отпрепаренных запросов на 100 потоков, выполняющиеся по 1000 раз в секунду, чем 100000 раз парсить и выполнять запросы.
no subject
Date: 2010-12-16 09:18 am (UTC)Естественно, что лучше 100 отпрепаренных запросов. Но это вопрос к конкретному приложению. Рассматриваемый пример несколько искусственен. Не знаю тонкостей мускула и использованных тулз, но могу предположить, что после второго запроса там уже все из кеша бралось по факту, так что измерялась очень вакуумно-сферическая величина, в которой естественно первое место занял парс.
no subject
Date: 2010-12-16 09:27 am (UTC)no subject
Date: 2010-12-16 08:31 pm (UTC)