на первый пять предпочту не отвечать.
> 6. Тьфу, бла, это перевод… Афтар! Убей сибя ап стены, т. е. юзай топик-ссылки… :(
хотелось бы посмотреть на оригинал
Нууу. Если вам _действительно_ нужно, чтобы id были монотонно возрастающими, то можно позаботиться о том, чтобы руками никто из таблицы не удалял и делать truncate table вместо delete from table
Думаю, что про то, что перечесление полей или звездочка работают быстрее друг друга говорить не стоит. Отличия если и есть, то они будут минимальными. А вот то, что вы получите замедление при выборке ненужных данных — это факт.
> А что Вы где-то видели, что комментарии к статье и тело статьи хранят в одной таблице?
Я видел, когда вместе со статьями хранят счетчики комментов к ней (об этом и написано).
Вы не можете гарантировать, что запрос не будет вытеснен из кеша, тогда как на уровне приложения можете. Если это тяжелая выборка, и вы хотите, чтобы результат был в обязательно в кеше, то кешируйте на стороне приложения.
Заглянул в код. В коде все по написаному:
/*
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». Так что, все-таки — это происки клиента и комментарии в начале запроса писать не стоит.
Действительно странное дело. Информация эта была в выступлении Baron Schwartz'а на одной из конференций и нескольких других публикациях.
Сам проверил сейчас — тоже работает все как нужно. Но это притоворечит логике — MySQL смотрит в кеш ДО парсинга запроса. Возможно, что это проделки клиента. Как выясню точно, напишу.
> 6. Тьфу, бла, это перевод… Афтар! Убей сибя ап стены, т. е. юзай топик-ссылки… :(
хотелось бы посмотреть на оригинал
рад, что развесилил вас.
> не бывает таблиц без удаленных строк
Очень даже бывают. Если удалений не много, то строки можно не удалять, а помечать как удаленные.
Я видел, когда вместе со статьями хранят счетчики комментов к ней (об этом и написано).
/*
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 смотрит в кеш ДО парсинга запроса. Возможно, что это проделки клиента. Как выясню точно, напишу.