Форум MySQL

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

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

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

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

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

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

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

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

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

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

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

CREATE INDEX mail_vse ON str_vh, poisk_fr, skolko

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

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

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

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

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

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

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

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