Форум MySQL

В базе используется вот такая таблица:

<?php $query = "CREATE TABLE kattov (     id         INT     (11) NOT NULL AUTO_INCREMENT,     group_id   INT     (6),     producer   VARCHAR (100) CHARACTER SET utf8,     artikul    VARCHAR (50),     name_tov   VARCHAR (400) CHARACTER SET utf8,     cena       DECIMAL (18, 8),     kol        INT     (6),     guid       VARCHAR (40),     metka      CHAR    (4),     PRIMARY KEY(id) ) ENGINE=MyISAM CHARACTER SET utf8";     mysql_query($query);     // Создание UNIQUE $query = "ALTER TABLE kattov ADD UNIQUE (producer, artikul, name_tov, metka)"; mysql_query($query);

Все поля ужаты до предела, а UNIQUE необходимо из условия её наполнения, так что для радикальной оптимизации, вроде бы, серьезных средств нет.

Одно обращение клиента к серверу за информацией вызывает серию из 100-150 запросов к базе с поиском по артикулу. Оптимизировать количество запросов тоже не представляется возможным, поскольку это проистекает из сущности самого сервиса.

Полный процесс обслуживания клиента (вся серия запросов) занимает 4-5 секунд. Вроде бы, это и немного, но это при количестве записей всего лишь один миллион. Но если будет десять миллионов записей, то это уже нехорошо…
(Сейчас размер базы 250 Мб, причем почти все – таблица kattov).

В этой связи возникает такая идея: создать вторую базу (именно базу!), содержащую только одну таблицу, включающую в себя поле с артикулом и поле с номером строки в таблице с товаром из первой базы (id). Очевидно, что вторая база будет существенно меньше первой и ей не нужен UNIQUE, а потому поиск по артикулу во второй базе должен производиться гораздо быстрее. А уже по результатом поиска по второй базе произвести выборку из первой базы 100-200 строк по их id, произведя поочередно столько же запросов.

Будет от этого ли толк?

1. А у вас индекс используется при поиске по artikul? Вообще не должен, если artikul не стоит в начале индекса.
2. Лучше всего проблемные SELECT-запросы посмотреть через EXPLAIN, чтобы выяснить план запроса.
3. 100-150 запросов к одной таблице? Как правило, имеется возможность их сократить (очень редко нельзя уменьшить их количество).
>В этой связи возникает такая идея: создать вторую базу (именно базу!)
4. Никакой выгоды в этом нет, вторая база - просто директория. Если создадите таблицу в этой же базе данных - ничего не поменяется, а работать будет удобнее.
>содержащую только одну таблицу, включающую в себя поле с артикулом и поле с номером строки в таблице с товаром из
>первой базы (id).
Вполне себе подход, только попробуйте сначала просто завести второй индекс только для artikul. В MyISAM индексы храняться отдельно от данных, возможно вам ничего не потребуется заводить.

попробуйте сначала просто завести второй индекс только для artikul

$query = "ALTER TABLE kattov ADD INDEX (artikul)" дало очень существенный выигрыш, спасибо! В особенности в случаях, когда искомого товара нет в базе (а это больше половины запросов). Я так понимаю, что в этом случае MySQL, по сути, ничего и не ищет, поскольку по индексу видит, что нечего искать.

А вот исполнение INSERT замедлилось.

Собственно, так и должно быть, но читать об этом в книге - это одно, а наблюдать своими глазами - это несколько другое. Интересно!

Правильно ли я понимаю, что в отличие от UNIQUE, использование INDEX допускает и повторяющиеся, одинаковые записи?

Еще интерессно было бы понять, почему EXPLAIN не показывает наличие UNIQUE (скриншот)?

>Правильно ли я понимаю, что в отличие от UNIQUE, использование INDEX допускает и повторяющиеся, одинаковые записи?
Совершенно верно.

>Еще интерессно было бы понять, почему EXPLAIN не показывает наличие UNIQUE (скриншот)?
Это возможный ключ, ключ-кандидат, в отчете на скриншоте сообщается, что индексы в запросе задействованы не будут и запрос просканирует всю таблицу полностью.