Оптимизация работы с MySQL

была статья на эту тему: habrahabr.ru/blogs/mysql/44608/

Оптимизация MySQL запросов

еще напишите для него обертку, типа function bulk_update(), чтобы не склеивать каждый раз строчку

Оптимизация MySQL запросов

на первый пять предпочту не отвечать.
> 6. Тьфу, бла, это перевод… Афтар! Убей сибя ап стены, т. е. юзай топик-ссылки… :(
хотелось бы посмотреть на оригинал

Оптимизация MySQL запросов

Нууу. Если вам _действительно_ нужно, чтобы id были монотонно возрастающими, то можно позаботиться о том, чтобы руками никто из таблицы не удалял и делать truncate table вместо delete from table

Оптимизация MySQL запросов

Ну или возьмите например хабр. Блоги удалять нельзя. Их можно только делать закрытыми. Получаем таблицу без дыр с id — первичным ключом.

Оптимизация MySQL запросов

> а ваши примеры — на смех
рад, что развесилил вас.

> не бывает таблиц без удаленных строк
Очень даже бывают. Если удалений не много, то строки можно не удалять, а помечать как удаленные.

Оптимизация MySQL запросов

да, вы правы

Оптимизация MySQL запросов

время-то не раннее :)

Оптимизация MySQL запросов

Думаю, что про то, что перечесление полей или звездочка работают быстрее друг друга говорить не стоит. Отличия если и есть, то они будут минимальными. А вот то, что вы получите замедление при выборке ненужных данных — это факт.

Оптимизация MySQL запросов

опередил :)

Оптимизация MySQL запросов

это для краткости изложения :)

Оптимизация MySQL запросов

Да, пример совсем не кассу получился. Спасибо, исправил

MySQL Query Cache

> А что Вы где-то видели, что комментарии к статье и тело статьи хранят в одной таблице?
Я видел, когда вместе со статьями хранят счетчики комментов к ней (об этом и написано).

MySQL Query Cache

смущает очень большое количество Qcache_not_cached и большое кол-во незанятой памяти

MySQL Query Cache

Вы не можете гарантировать, что запрос не будет вытеснен из кеша, тогда как на уровне приложения можете. Если это тяжелая выборка, и вы хотите, чтобы результат был в обязательно в кеше, то кешируйте на стороне приложения.

MySQL Query Cache

show global status like 'Com_select'; — показыват сколько запросов было непосредственно выполнено сервером, а не взято из кеша

MySQL Query Cache

перечитайте статью, там написано :)

MySQL Query Cache

В чем не срастается-то? «Многие» != «все»

MySQL Query Cache

Заглянул в код. В коде все по написаному:
/*
Test if the query is a SELECT
(pre-space is removed in dispatch_command)

First '/' looks like comment before command it is not
frequently appeared in real life, consequently we can
check all such queries, too.
*/

if ((my_toupper(system_charset_info, sql[i]) != 'S' ||
my_toupper(system_charset_info, sql[i + 1]) != 'E' ||
my_toupper(system_charset_info, sql[i + 2]) != 'L') &&
sql[i] != '/')
{
DBUG_PRINT(«qcache», («The statement is not a SELECT; Not cached»));
goto err;
}

При выборке из кеша идет именно проверка на эквивалентность первых символов запроса строке «SEL». Так что, все-таки — это происки клиента и комментарии в начале запроса писать не стоит.

MySQL Query Cache

Действительно странное дело. Информация эта была в выступлении Baron Schwartz'а на одной из конференций и нескольких других публикациях.
Сам проверил сейчас — тоже работает все как нужно. Но это притоворечит логике — MySQL смотрит в кеш ДО парсинга запроса. Возможно, что это проделки клиента. Как выясню точно, напишу.