[DB]Выбрать opensource DB.

Просто так абы как - нет.

небось group by

Смысла нет, пока вы не попробовали оптимизировать работающее сейчас решение.

DELETE FROM temp_ban;INSERT INTO draft_squid SELECT * FROM squid where status=0 AND trans<>'NONE/-';UPDATE squid set status=1 where status=0;INSERT INTO temp_ban (ip,mbytes,lim,name) SELECT draft_squid.ip,SUM(draft_squid.bytes)/1048576,user_squid.lim,user_squid.name FROM draft_squid INNER JOIN user_squid ON RTRIM(draft_squid.ip)=RTRIM(user_squid.ip) GROUP BY draft_squid.ip,user_squid.name,user_squid.lim;SELECT name INTO OUTFILE '/etc/squid/ban/bans.txt' FROM temp_ban WHERE (lim-mbytes)<0; select name into outfile '/etc/squid/ban/bank.txt' from user_squid inner join squid on squid.ip=user_squid.ip where month(squid.time)=month(curdate()) and year(squid.time)=year(curdate()) and user_squid.id=4 group by user_squid.name HAVING sum(squid.bytes)/1048576>(select user_squid.lim from user_squid where id=4);
Примерно такие.

Скорее всего имеет, MySQL не очень-то дружит с такими объёмами.

P.S.
Писал wiki-движок вообще на Berkley DB. Вот это я понимаю, скорость. К тому же от объёма БД почти не зависит.

Поддержка таблиц BDB включена в дистрибутив исходного кода MySQL начиная с версии 3.23.34 и в бинарную версию MySQL-Max. BerkeleyDB обеспечивает транзакционный обработчик таблиц для MySQL.

Поддержка таблиц BDB включена в дистрибутив исходного кода MySQL начиная с версии 3.23.34 и в бинарную версию MySQL-Max. BerkeleyDB обеспечивает транзакционный обработчик таблиц для MySQL.

http://dev.mysql.com/doc/refman/5.0/en/bdb-storage-engine.html

Да и смысла в ней в MySQL ровно ноль.

OPTIMIZE TABLE давно делал?

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

Форматирование Саша Пушкин будет делать? Я в суд подам за нанесения морального вреда моим глазам, они теперь смотрят в разные стороны.

Последний запрос просто ужас, боюсь даже интересоваться структурой базы, для которой нужны такие запросы :(

адвокату моему позвони.

Для этого надо останавливать сервис

Нет, не нужно.

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

Ты ты схему показал чтоль? С запросами и распределением нагрузки на запросы. С нормальным форматированием! Иначе это тред ни о чем.

он о mysql vs postgresql :-)

Нет, не нужно.

я имел ввиду доступ к сервису.

>Для этого надо останавливать сервис

разве мускуль не умеет это в фоне делать? Надо будет ман покурить.
И думать надо было раньше, на этапе проектирования. А с таким подходом можно любую базу засрать, хоть мускуль, хоть постгрес, хоть оракл.

да я имел в виду не сервис mysql а сервис для пользователей. Надо было покурить.

>сервис для пользователей
а зачем его останавливать? :)

потому что таблица блокируется.

>потому что таблица блокируется.
ну значит не выполняется в фоне :) Зачем ты тогда уточнял, что ты останавливаешь? Очевидно же, что для выполнения своих функций mysqld должен быть запущен :)

и какой там сейчас объем базы?

около четырех гигов.

>адвокату моему позвони.

Мне теперь окулист важнее :)

Вот таже проблема меня ждёт. Ибо сервис что делаю сейчас подразумевает большую свалку информации, которая копится быстрее чем размножаются кошки в dwarf fortress.
Сейчас пока юзаю SQLAlchemy с SQLite, но на продакшне хотел юзать mysql.

PS: Триггеры в базе есть? IMHO ими судя по приведенным запросам и не пахнет.

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

На мой взгляд посгрес в самом деле быстрее на таких объемах, не говоря уже о надежности.

толстовато будет :) Можно попробовать пересоздать таблицы, при такой засранности это будет быстрее оптимизации. Но о регулярной оптимизации подумать стоит, другая СУБД тут не панацея.

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

Firebird будет достаточно.

я думал ты будешь всеми конечностями за postgresql :-)