Нужен совет!

Имеется таблица порядка 1.5 млн. записей.
В нее постоянно ведется запись (добавление новых 10% и обновление существующих записей 90%) и чтение.
Соотношение записи и чтения примерно 1/3.
Но поскольку обращений очень много, то тормоза стоят жуткие.
В списке процессов по 200-300 и более записей из них 90% в состоянии lock.

Посоветуйте, как разрулить ситуацию?

PS: Назначение таблицы - анкеты пользователей системы знакомств.
Постоянно регистрируются новые, изменяют параметры старые.
И очень-очень много поисковых запросов.

База MySQL

iscrafmнасколько помню, в MySQL нет хинта NOLOCK (речь конечно же не идет об InnoDB?),...
скорее всего READ UNCOMMITED для поисковых запросов решит проблему.

В мануале про READ UNCOMMITED ничего нет.
Речь точно идет о MySQL ?

Мне также предложили InnoDB.
Вот только кроме построчной блокировки никакие другие
возможности не нужны. А нагрузка из-за перехода возрастет
(и на память, на процессор, на диск) - вроде как лишнее.

Интересно есть ли какие-то эффективные трюки?
Сейчас пробовал делать копию базы для поиска.
Но по времени залочить и закрыть таблицу, а потом
скоприровать почти 1Гб - от минуты и более занимет...
а в это время лок - так что тоже неахти...

Оказывается правильно это пишется так: READ UNCOMMITTED
Потому поиск и не находил (даже по mysql.com).

Надо попробывать.

А кстати, многие пропускают. Два M пишут, а вот T только одно.
Я даже подумал что это в Оракле синтаксис такой... :)
Пока не нашел такую же очепятку на mysql.ru :)

Такое впечатление, что READ UNCOMMITTED совсем не работает на MyISAM таблицах

делаю сразу после подключения к базе:
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

для всех клиентов. но результат тот же.

Ведь SET SESSION TRANSACTION влияет на всю сессию после подключения...
А так перед каждым запросом вставлять.

Сделал. Ничего не поменялось...

mysql> SELECT @@tx_isolation;
+-----------------+
| @@tx_isolation |
+-----------------+
| REPEATABLE-READ |
+-----------------+
1 row in set (0.00 sec)

Запросов море, селекты в локах...
Ладно бы апдейты в очередь ставились.
Ведь вся идея была чтобы селекты пропускать
(не по high_priority, а по "грязному").

Единственное, напомню что у меня MyISAM таблица.
А не InnoDB (пока этот вариант не трогаю)
Вся информация , в частности по @@tx_isolation;
в мануалах чаще соотносится с innodb

Прошу прощения статус меняется
+------------------+
| @@tx_isolation |
+------------------+
| READ-UNCOMMITTED |
+------------------+

Но на последующий запрос это не влияет.
mysql> select * from accounts limit 10;
...
Query OK, 10 rows affected (46.05 sec)

Она так же в локах провисел...

guest_20040621> Полезный совет: переходить на InnoDB и не страдать фигнёй.

Еще один полезный совет: переходить на PostgreSQL и не страдать фигней.

Да, на InnoDB уже решился :)
Только сначала организую установку 5-ой версии,
чтобы реализация посвежее была.

А вот про Postgre даже и не думал.
В принципе, не проблема. Другое дело что тема новая.
Нужно будет заняться изчением/сравнением.

А то что мы с READ UNCOMMITED бились, меня тоже засмущало.
Но "на авось" не сработало :)

Так что всем спасибо!
Буду изучать новую тему.