вопросы по LOCK таблиц и прочей оптимизации
 

Имеется форум на mysql. На сегодняшний день имеем такую статистику ( слева цифры того, что не помечено, как удаленное, в скобках - всего):
15 форумов (24 всего),
21 006 тем (30 427 всего),
311 815 сообщений (349 273 всего),
4 895 юзеров (5 015 всего)

Система явно растущая, т.к. по отношению к осзону за последний год был явный рост:
осзн сегодня: Темы: 66 240 тем (1/3 - год назад было примерно 1/5), Сообщения: 519 399 (1/1.5 - было примерно 1/5), участников: 60,426 (1/12 сколько было не помню, да и там можно постить гостям, так что принудительного роста нет :))

Так вот, собственно, у меня вопросы
1) в отсутствии нормальнгых транзакций: - сильно ли должен напрягать систему LOCK на таблицу при записи? И чем рискую, если от него отказаться?
2) сильно ли мешают эти самые псевдоудаленные "лишние" записи (т.е. поможет ли системе, если их удалять по-настоящему)?
3) напрягают ли mysql использование прямо в запросе функций:
--- DATE_FORMAT
--- REPLACE
--- CONCAT
--- сочетание нескольких CONCAT с двумя предыдущими
--- CEILING

Потом еще что-нибудь придумаю :)

чего то я лично вас не понял

вопрос в объеме ключей + лишняя фильтрация в запросе на выборку

это при выводе результатов или в момент поиска?

по 3 - при обработке показ результата (т.е. select функция as мои_преобразованные_поля)

по 1 - ты лично лочишь таблицы, когда юзер (с форума, например) добавляет (сильно реже - редактирует) запись?

mar
а что мешает использовать транзакции?

если по итогам не сортировать то вполне нормально.

версия mysql и тип таблиц

Сортировка есть, возможна по любым позициям (но по этим в системе не применяется).

mar
1) "версия mysql" - ниже чем 4.1?
2) база большая, наверное там дидикейтед сервер, неужели нельзя сменить тип таблиц?

там выделенный сервер. А ты работал с таблицами этих самых типов, поддерживающих транзакции? что-то у меня все это (включая качество транзакций) вызывает определенные сомнения. + издержки перехода (отличия-то будут)

mar
мы на работе с ними достаточно долго работаем.

если обваливается то все назат от катывает что и нужно.

будут, в основном по другому идут алгоритмы выборки + наблюдается некоторое замедление
а так чтоб картинально что то по другому работало не замечали...

вот я как раз об этом. Замедление - это то, чего мне категорически не нужно =) (Это же форум, а не ваша специализированная система)

mar
вот именно это же форум, а не наша специализированная системма, и нагрузку он дает меньше...

если ты будешь использовать лок таблиц то это скорее всего на много больше заметлит системму + недай бод произойдет дедлок!

подумаю. Пока после некоторого тюнинга все пошло работать достаточно быстро. В конце-концов следующий тюнинг может быть просто переходом на постгрес =)

mar
ну уж тогда на оракл к примеру ;)

Vlad Drakula
интересно, но для этой задачи не нужно и даже вредно :)

mar
почему же?

покупать оракл для форума - не смешно, а использовать free-полнофункциональный ознакомительный вариант - нарушение, а free-вариант, если мне не изменяет память, не поддерживает многопроцессорность. Между тем многопроцесорность для СУБД дает реальный прирост в работе, особенно на сложных запросах.

mar
1) сам оракл не запрещает использовать бесплатную в коммерческих целях
2) основныз ограничений два: 4Гб + один процессор

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

Vlad Drakula
так я про эту версию и писала. Один процессор - это зло. "использовать более оптимальные алгоритмы" надо всегда, но зачем же специально ораничиваться? нет уж. Пока все летает за счет оптимизации. Следующая оптимизация будет переездом на постгрес =)

(+ Есть еще один free-вариант - без всяких органичений, но для личного использования - поставить дома и отлаживать)

mar
постгрес - явно на много медленнее чем оракл
и полтора процессора его не спасут!