powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Оптимизация базы для сайта знакомств
7 сообщений из 7, страница 1 из 1
Оптимизация базы для сайта знакомств
    #33450060
Нариман
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Есть база пользователей и поиск по ней,

база:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
CREATE TABLE users (
   login varchar( 32 ) NOT NULL,
   pass varchar( 32 ) NOT NULL,
   mail varchar( 128 ) NOT NULL,

   gender char( 1 ) NOT NULL,
   active char( 1 ) NOT NULL,
   logTime datetime DEFAULT '0000-00-00 00:00:00' NOT NULL,
   regTime datetime DEFAULT '0000-00-00 00:00:00' NOT NULL,

   photoHave int( 1 ) unsigned DEFAULT '0' NOT NULL,
   messNew int( 3 ) unsigned DEFAULT '0' NOT NULL,

   и.т.д еще  55  полей
   PRIMARY KEY (login),
   KEY mainSearch (gender, photoHave)
}

делалось так чтобы избежать join таблиц,
при нагрузке 15000 хостов, 100 000 страниц в день система находится в вечно загруженном состоянии :(

Порядок стандартных действий на сайте
логин пользователем на сайт
Код: plaintext
1.
select login, pass where login AND pass
update (logTime)
0.08 - 0.10 сек

стандартное условие, пользователь active, пол =F, есть фото
Код: plaintext
$where_add = "active = 'Y' AND gender = 'F' AND photoHave != 0"

Выборка пользователей происходит в два действия

получение количества пользователей подпадающих под запрос
Код: plaintext
1.
$sql = "SELECT COUNT(login) as numRows FROM users WHERE ".$where_add;
$numRows = mysql_result(mysql_query($sql),  0 ,  0 );
0.15 - 0.2 сек

получение списка пользователей
Код: plaintext
SELECT * FROM users WHERE ".$where_add." ORDER BY regTime DESC
0.15 - 0.2 сек

В итоге эти 3 действия обычно блокируют друг друга и растет кол-во коннектов, через n-time люди просто уходят с сайта, и все нормализуется.

Вопрос как можно обойти эти пики активности ?
...
Рейтинг: 0 / 0
Оптимизация базы для сайта знакомств
    #33450100
Нариман
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
как я понимаю основным вариантом является разбивка таблицы на части такие как

Код: plaintext
1.
2.
3.
4.
5.
6.
CREATE TABLE usersSearch (
   login varchar( 32 ) NOT NULL,
   gender char( 1 ) NOT NULL,
   active char( 1 ) NOT NULL,
   photoHave int( 1 ) unsigned DEFAULT '0' NOT NULL,
   regTime datetime DEFAULT '0000-00-00 00:00:00' NOT NULL,
}


Код: plaintext
1.
2.
3.
4.
5.
CREATE TABLE usersLogin (
   login varchar( 32 ) NOT NULL,
   pass varchar( 32 ) NOT NULL,
   messNew int( 3 ) unsigned DEFAULT '0' NOT NULL,
   logTime datetime DEFAULT '0000-00-00 00:00:00' NOT NULL,
}

все остальные поля в таблицу users .

Главный вопрос в чем,
1. Разбить таблицу по полям причем каждое поле только в 1 таблице,
и при желании допустим получить пол при логине join дополнительные талицы


2. Сделаем зеркальные копии нужных таблиц и затем при обновлении вставлять во все таблицы записи, получается вроде view, при этом имеем проблемы с целостностью и непротиворечивостью данных. Зато не имеем геммороя с вытаскиванием нужного поля из кучи таблиц

Гуру подскажите, будьте добры.
...
Рейтинг: 0 / 0
Оптимизация базы для сайта знакомств
    #33450120
Фотография 4m@t!c
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На вскидку сделайте KEY(active, gender, photoHave) потому что по этим трем полям вы ищете.
И еще вы пользуете РНР?
----------------------------------------
Артисты не приехали, приехали цыгане
...
Рейтинг: 0 / 0
Оптимизация базы для сайта знакомств
    #33450152
Нариман
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
4m@t!cНа вскидку сделайте KEY(active, gender, photoHave) потому что по этим трем полям вы ищете.
И еще вы пользуете РНР?
----------------------------------------


у хостера стоит PHP 4.3.4 на машине класса P4 3Ghz 1 Gb SCSI винты,
и как не странно MYSQL 3.23 на машине класса P2 600 Mhz
(в разное время собиралась площадка для хостинга :)

сайт активен только этот, остальные ~1000 запросов в день,

индекс по полям (active, gender, photo) время выборки одной записи не превышает 0.08,

вопрос в том что потом он эту запись fetch в PHP, что занимает уже гораздо дольше, в итоге в процессах, стандартный набор
Код: plaintext
1.
LOCKED UPDATE USERS
SENDING DATA SELECT

:(
...
Рейтинг: 0 / 0
Оптимизация базы для сайта знакомств
    #33450185
Фотография 4m@t!c
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>вопрос в том что потом он эту запись fetch в PHP
а причем зедсь "LOCKED UPDATE USERS SENDING DATA SELECT" - я не понимаю.
----------------------------------------
Артисты не приехали, приехали цыгане
...
Рейтинг: 0 / 0
Оптимизация базы для сайта знакомств
    #33450196
Нариман
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
сорри наверное криво объясняю,

смысл такой если выполнить
SHOW PROCESSLIST;

в mysql то видим, что большинство времени занимает
Код: plaintext
Sending Data для Select ов, до  10 - 15  секунд,

и накапливается большое количество
Код: plaintext
блокировок связанных с UPDATE таблицы USERS,
(похоже из-за того что туда записывается информация о дате и времени последнего Login)
...
Рейтинг: 0 / 0
Оптимизация базы для сайта знакомств
    #33450390
DocAl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1. Включите логирование долгих запросов.
2. Проанализируйте их. Весьма вероятно, что будет достаточно построить соответствующие индексы, или проверить и восстановить имеющиеся.
3. Если у вас структура запросов к базе смешанная, и параллельно с селектами регулярно идут апдейты -- подумайте о переводе таблиц на движок InnoDB, он имеет построчную блокировку вместо табличной.
...
Рейтинг: 0 / 0
7 сообщений из 7, страница 1 из 1
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Оптимизация базы для сайта знакомств
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]