Форум MySQL

У меня есть три mysql таблицы вида (int 11)key = (char 255)value.
Данные в каждой таблице разные.
За каждый вызов любой страницы сайта выбираются все данные из трех таблиц.
Таблицы обновляются где-то каждый 1% от всех обращений к серверу, чем больше нагрузка - тем меньше процент.
Еще с меньшей регулярностью некоторые строки становятся ненужными.

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

Какие еще есть варианты оптимизации? Желательно уйти от mysql и в тоже время, чтобы шустро работало просто на хорошем хостинге.

А в таблицу типа MEMORY не хотите поместить эти данные? Будет быстрее чем файл. Как вариант можно формировать PHP-массивы и подключать их при помощи require().

Я только не очень представляю себе корректную работу механизма с MEMORY.

После падения сервера MEMORY таблица очищается.

При обращении каждый раз придется делать COUNT строк и если они там вообще есть - то брать информацию оттуда, в противном случае лезть в MYISAM таблицу и переливать данные в MEMORY, потом снова запрос ну и дальше понятно.

А что будет если первый пользователь запустил такую процедуру, а другой пользователь в это время попросил строку из конца таблицы, его COUNT вернет то количество строк, которые успели записаться, или будет стоять в очереди?

Как этот момент проконтролировать?
Может самопальную блокировку сделать, или для этого есть встроенные средства?

А в целом решение мне нравится.

Это не файлы, в СУБД очередь запросов - пока таблица будет заполняться, она блокируется автоматически (по крайней мере таблицы типа MyISAM и MEMORY), все остальные запросы будут ожидать - т.е. они даже не приступят к вычислению количества строк, пока не отработает запрос на заполнение таблицы (тем более данные можно вставить при помощи одного запроса). Т.е. собственные блокировки вводить нет надобности.

Спасибо.

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

CREATE TABLE `" . MYSQL_PREFIX . "v_temp` (      `id` INT ( 11 ) NOT NULL,      `data` CHAR ( 255 ) NOT NULL ,      PRIMARY KEY ( `id` ) ,      KEY `v_temp` ( `data` )      )ENGINE = MEMORY DEFAULT CHARSET = utf8;      CREATE TABLE `" . MYSQL_PREFIX . "v_temp` (      `id` INT ( 11 ) NOT NULL,      `data` CHAR ( 255 ) NOT NULL ,      PRIMARY KEY ( `id` ) ,      INDEX ( `data` )      )ENGINE = MEMORY DEFAULT CHARSET = utf8;

И нужен ли этот индекс вообще, если второго запроса на выборку избежать с помощью средстр php?

SELECT `data` FROM `v_temp` WHERE `id` = '5'; SELECT `id` FROM `v_temp` WHERE `data` = 'тратата';

Оба нужны, если будут указанные запросы

CREATE TABLE `" . MYSQL_PREFIX . "v_temp` (       `id` INT ( 11 ) NOT NULL,       `data` CHAR ( 255 ) NOT NULL ,       PRIMARY KEY ( `id` ) ,       KEY `v_temp` ( `data` ),      INDEX ( `data` )      )ENGINE = MEMORY DEFAULT CHARSET = utf8;

Если второго запроса сможете избежать (это желательно бы), то можно оставить индекс только по id.

PS Под новые вопросы лучше заводить новые темы.

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

Я вообще запутался.

>Если второго запроса сможете избежать (это желательно бы), то можно оставить индекс только по id.

Значит KEY `v_temp` ( `data` ), INDEX ( `data` ) требуются только для второго запроса.

Ключи создаются чтобы запрос выполнялся не в общей таблице, а непосредственно в таблице ключей(а). Создав два ключа для одного поля поиск как я понял будет осуществляться учитывая оба ключа, хотя про два ключа для одного поля я впервые слышу.

Какой-то двойной ключ получается. Это действительно помогает? Из каких соображений?

Предположим, что достаточно только один раз обратиться в таблицу и взять все данные. В этом случае можно же совсем не ставить ключи, или первичный ключ ускорит выборку?

SELECT `id`, `data` FROM `v_temp`;

Да, ошибся, один ключ должен быть для data, другой для id.

>Ключи создаются чтобы запрос выполнялся не в общей таблице, а непосредственно в таблице
>ключей(а). Создав два ключа для одного поля поиск как я понял будет осуществляться учитывая
>оба ключа.
Не совсем, это от запроса зависит, иногда можно обойтись без данных, иногда нет, в любом случае ключ ускорит запрос. Имелось в виду ключ для каждого из столбцов id и data.