Форум MySQL

Диагностика базы, выполненная PhpMyAdmin, указывает на непорядок с параметром Select_full_join. Его значение равно 36 и указано красным. А в комментарии сказано:

Количество запросов-объединений, выполненных без использования индексов. Если значение переменной не равно 0, рекомендуется проверить индексы таблиц.

Как их проверить, эти индексы?

Прямо это и значит, наверное: где-то не проставлены индексы, от чего JOIN-запросы медленно выполняются. Например, есть у Вас запрос "SELECT ... FROM `accounts` `t1` JOIN `photos` `t2` ON `t1`.`id` = `t2`.`account_id` ...". Если в таблице photos на "account_id" не будет стоять индекс, то в лучшем случае он медленно выполнится. В худшем, на мой взгляд, может вообще не выполнится, так MySQL без индексов должен будет сверить все комбинации id и account_id (кол-во строк accounts x кол-во строк photos), а это может быть каким-то запредельным числом.

А где, если не секрет, в phpMyAdmin Вы такое увидели? У меня phpMyAdmin 2.11.5, там вроде диагности баз данных нет...

SHOW STATUS
http://dev.mysql.com/doc/refman/5.1/en/server-status-variables.html#statvar_Select_full_join

PMA: Гл.страница / показать состояние MySQL

А как это значение подсчитывается, не знаете?

В смысле?
Как сервер считает сколько раз полное сканирование таблиц делал при JOIN ?
Так и считает. А как это можно считать?

Я сейчас посмотрел - у меня тоже ненулевое значение. Просто так поставил где-то индекс. Значение не изменилось (аналогия с кешем -- если выполнить запрос UPDATE, то все кеш запросов к обновляемой таблице удаляется). Отсюда я предполагаю, что MySQL где-то сохраняет сами запросы или во всяком случае таблицы, где зафиксировано отсутствие индексов. Вот и думаю где можно это посмотреть.

>Я сейчас посмотрел - у меня тоже ненулевое значение. Просто так поставил где-то индекс. Значение не изменилось ...

Это счетчик. Счетчик запросов.
Почему он должен был поменяться?
Сделайте FLUSH STATUS - все счетчики скинутся в 0.

Понятно, я просто подумал это как связано с slow query log.

"где-то не проставлены индексы"
Я что ли их проставляю?

Таблицы создаю примерно так:

$query = "CREATE TABLE mail_vse         (               id       INT     (11) NOT NULL AUTO_INCREMENT,               str_vh   VARCHAR (99),             poisk_fr VARCHAR (200),             skolko   INT     (10),               PRIMARY KEY(id)         ) ENGINE=MyISAM CHARACTER SET cp1251";         mysql_query($query);

Признаться, я так и не понял, каким образом проверить индексы таблиц.
Да и вообще ничего не понял: я делаю запросы, какие мне нужны по логике скрипта. Что, их нужно составлять каким-то особым образом, специально задавая индексы? Или что?

======================
Кстати, JOIN не использую вообще.

skolko можно смело индексировать.
>Кстати, JOIN не использую вообще.
Двухтабличные или вложенные запросы используются?

"Двухтабличные или вложенные запросы используются?"
Нет.

"skolko можно смело индексировать"
Как? Что конкретно для этого мне следует сделать?

>skolko можно смело индексировать.
Но почему? Только потому что оно короткое?
Откуда информация, что это поле применяется для сопоставления строк таблиц?

Да, никакого, я поэтому и задал предыдущий вопрос о том, какие запросы используются. По сути никто кроме Владимира не скажет как лучше индексировать таблицы, так как он один знает, какие запросы наиболее интенсивно используются. Даже если он полностью опишет струтуру таблиц для точного диагназа, этой информации будет мало, нужно будет знать, что делает код. Мне кажется проще Владимира накачать информацией о ключах, чем ткнуть в таблицы его базы данных и сказать, где и что проиндексировать.

Я вот сейчас в очередной раз перебрал Самоучитель и Практику создания сайтов, но так и не понял, что есть индексация в данном контексте. Это такой оператор? Или что?

А мы в Самоучителе этот вопрос и не рассматривали подробно, он был отложен до MySQL 5 в подлинике. Если на пальцах, индексация, это создание на жестком диске или в оперативной памяти заранее отсортированного порядка записей. Ключи здорово ускоряют выборку оператором SELECT и приводят к замедлению операторов DELETE, UPDATE и т.п. (так как каждый раз приходится помимо записи, ещё и ключи добавлять/сортировать). Да, ключи создаются отдельным оператором CREATE INDEX или в составе оператор CREATE TABLE (собственно создание первичного ключа вы можете наблюдать у себя в таблице).

Работу создаваемого скрипта я разделяю на две части:
1. Накопление информации в реальном времени;
2. Административная обработка информации (и автоматически в заданное время).

В первой части операторы SELECT, DELETE и UPDATE не используются, а приходится довольствоваться INSERT INTO. Информация пишется "внавал", что, как я надеюсь, обеспечивает наибольшее быстродействие.
Ежесуточно таблицы укорачиваются путем удаления информации за предыдущий день.

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

Если я правильно понял Ваше разъяснение, то индексировать таблицы, работающие в первой (оперативной) части скрипта. не надо. Так?

А проиндексировать таблицы второй (административной) части можно.
Вообще то, я их пускаю на TRUNCATE перед началом работы, за исключением архива. Так что индексировать следует только архив. Верно?

Применительно к приведенной в примере таблицы для индексации надлежит выполнить запрос

CREATE INDEX mail_vse ON str_vh, poisk_fr, skolko

Так индексировать?

В надежде, что cheops выскажет свое веское мнение.

Что-то пропустил ваше сообщение. Да, совершенно верно, в первом случае индексы просто вредны - чем больше индексов, тем медленее наполняются таблицы.
>Если я правильно понял Ваше разъяснение, то индексировать таблицы, работающие в
>первой (оперативной) части скрипта. не надо. Так?
Совершенно верно.

>Вообще то, я их пускаю на TRUNCATE перед началом работы, за исключением архива. Так
>что индексировать следует только архив. Верно?
Абсолютно верно.

>CREATE INDEX mail_vse ON str_vh, poisk_fr, skolko
Не совсем так, дело в том, что при индексировании полей типа VARCHAR вы должны указать, сколько символов вы индексируете - чем больше символов, тем быстрее поиск, но медленее вставка
CREATE INDEX mail_vse ON str_vh (str_vh(99));
Вообще чем меньше цифра - тем лучше, если у вас в поле хранятся строки длиной преимущественно в 50-60 символов - такую цифру и указывайте.

БОЛЬШОЕ СПАСИБО!