|
|
|
| У меня есть три mysql таблицы вида (int 11)key = (char 255)value.
Данные в каждой таблице разные.
За каждый вызов любой страницы сайта выбираются все данные из трех таблиц.
Таблицы обновляются где-то каждый 1% от всех обращений к серверу, чем больше нагрузка - тем меньше процент.
Еще с меньшей регулярностью некоторые строки становятся ненужными.
Можно объединить три таблицы в одну добавив еще одно поле, но тогда будет большое количество строк.
Можно положить эти данные в 3 файла и брать их оттуда, все таки на 3 mysql запроса меньше. Это даже позволит в некоторых случаях вообще не подключаться к mysql, хотя тоже не большой процент.
Какие еще есть варианты оптимизации? Желательно уйти от mysql и в тоже время, чтобы шустро работало просто на хорошем хостинге. | |
|
|
|
|
|
|
|
для: deimand
(17.04.2011 в 22:55)
| | А в таблицу типа MEMORY не хотите поместить эти данные? Будет быстрее чем файл. Как вариант можно формировать PHP-массивы и подключать их при помощи require(). | |
|
|
|
|
|
|
|
для: cheops
(17.04.2011 в 23:48)
| | Я только не очень представляю себе корректную работу механизма с MEMORY.
После падения сервера MEMORY таблица очищается.
При обращении каждый раз придется делать COUNT строк и если они там вообще есть - то брать информацию оттуда, в противном случае лезть в MYISAM таблицу и переливать данные в MEMORY, потом снова запрос ну и дальше понятно.
А что будет если первый пользователь запустил такую процедуру, а другой пользователь в это время попросил строку из конца таблицы, его COUNT вернет то количество строк, которые успели записаться, или будет стоять в очереди?
Как этот момент проконтролировать?
Может самопальную блокировку сделать, или для этого есть встроенные средства?
А в целом решение мне нравится. | |
|
|
|
|
|
|
|
для: deimand
(18.04.2011 в 01:46)
| | Это не файлы, в СУБД очередь запросов - пока таблица будет заполняться, она блокируется автоматически (по крайней мере таблицы типа MyISAM и MEMORY), все остальные запросы будут ожидать - т.е. они даже не приступят к вычислению количества строк, пока не отработает запрос на заполнение таблицы (тем более данные можно вставить при помощи одного запроса). Т.е. собственные блокировки вводить нет надобности. | |
|
|
|
|
|
|
|
для: cheops
(18.04.2011 в 01:53)
| | Спасибо. | |
|
|
|
|
|
|
|
для: cheops
(18.04.2011 в 01:53)
| | Какой индекс предпочтительней использовать, в первом варианте или во втором?
И тот и тот запрос на создание таблицы 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` = 'тратата';
|
| |
|
|
|
|
|
|
|
для: deimand
(22.04.2011 в 15:08)
| | Оба нужны, если будут указанные запросы
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 Под новые вопросы лучше заводить новые темы. | |
|
|
|
|
|
|
|
для: cheops
(22.04.2011 в 15:22)
| | Вопрос вроде тот же, просто я пока обдумывал ваши первые ответы прошло несколько дней. Если будет правильней, то перенесите в новую тему.
Я вообще запутался.
>Если второго запроса сможете избежать (это желательно бы), то можно оставить индекс только по id.
Значит KEY `v_temp` ( `data` ), INDEX ( `data` ) требуются только для второго запроса.
Ключи создаются чтобы запрос выполнялся не в общей таблице, а непосредственно в таблице ключей(а). Создав два ключа для одного поля поиск как я понял будет осуществляться учитывая оба ключа, хотя про два ключа для одного поля я впервые слышу.
Какой-то двойной ключ получается. Это действительно помогает? Из каких соображений?
Предположим, что достаточно только один раз обратиться в таблицу и взять все данные. В этом случае можно же совсем не ставить ключи, или первичный ключ ускорит выборку?
SELECT `id`, `data` FROM `v_temp`;
|
| |
|
|
|
|
|
|
|
для: deimand
(22.04.2011 в 19:25)
| | Да, ошибся, один ключ должен быть для data, другой для id.
>Ключи создаются чтобы запрос выполнялся не в общей таблице, а непосредственно в таблице
>ключей(а). Создав два ключа для одного поля поиск как я понял будет осуществляться учитывая
>оба ключа.
Не совсем, это от запроса зависит, иногда можно обойтись без данных, иногда нет, в любом случае ключ ускорит запрос. Имелось в виду ключ для каждого из столбцов id и data. | |
|
|
|