Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
PHP. Практика создания Web-сайтов (второе издание). Авторы: Кузнецов М.В., Симдянов И.В. MySQL 5. В подлиннике. Авторы: Кузнецов М.В., Симдянов И.В. Самоучитель MySQL 5. Авторы: Кузнецов М.В., Симдянов И.В. PHP Puzzles. Авторы: Кузнецов М.В., Симдянов И.В. PHP 5/6. В подлиннике. Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Форум MySQL

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум Структурный форум

тема: Оптимизация справочных таблиц
 
 автор: deimand   (17.04.2011 в 22:55)   письмо автору
 
 

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

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

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

  Ответить  
 
 автор: cheops   (17.04.2011 в 23:48)   письмо автору
 
   для: deimand   (17.04.2011 в 22:55)
 

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

  Ответить  
 
 автор: deimand   (18.04.2011 в 01:46)   письмо автору
 
   для: cheops   (17.04.2011 в 23:48)
 

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

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

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

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

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

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

  Ответить  
 
 автор: cheops   (18.04.2011 в 01:53)   письмо автору
 
   для: deimand   (18.04.2011 в 01:46)
 

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

  Ответить  
 
 автор: deimand   (18.04.2011 в 01:55)   письмо автору
 
   для: cheops   (18.04.2011 в 01:53)
 

Спасибо.

  Ответить  
 
 автор: deimand   (22.04.2011 в 15:08)   письмо автору
 
   для: 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` = 'тратата';

  Ответить  
 
 автор: cheops   (22.04.2011 в 15:22)   письмо автору
 
   для: 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 Под новые вопросы лучше заводить новые темы.

  Ответить  
 
 автор: deimand   (22.04.2011 в 19:25)   письмо автору
 
   для: cheops   (22.04.2011 в 15:22)
 

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

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

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

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

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

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

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

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

  Ответить  
 
 автор: cheops   (22.04.2011 в 19:36)   письмо автору
 
   для: deimand   (22.04.2011 в 19:25)
 

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

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

  Ответить  
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования