Вот два одинаковых по результату запроса. Первый это тот что исполняется биллингом при выборе всех пользователей с определенным тарифным планом, второй это тот же первый но доработан напильником. Время исполнения первого около 30-40 минут на базе из 3500 пользователей при этом блокируются таблицы в
биллинге, время исполнения второго меньше секунды.
SELECT users.id, users.login, users.basic_account, users.full_name, accounts.is_blocked
FROM users
LEFT JOIN users_accounts ON users.id=users_accounts.uid
LEFT JOIN accounts ON users_accounts.account_id=accounts.id
LEFT JOIN account_tariff_link ON accounts.id=account_tariff_link.account_id
WHERE ((users.is_deleted='0')
AND (accounts.is_deleted='0'))
AND ((account_tariff_link.tariff_id = '60'
AND account_tariff_link.is_deleted = '0') )
SELECT users.id, users.login, users.basic_account, users.full_name, accounts.is_blocked
FROM users, users_accounts, accounts, account_tariff_link
WHERE users.is_deleted='0'
and users.id=users_accounts.uid
and accounts.id=account_tariff_link.account_id
AND accounts.is_deleted='0'
and users_accounts.account_id=accounts.id
AND account_tariff_link.tariff_id='60'
AND account_tariff_link.is_deleted = '0'
Когда будем оптимизировать движок биллинга?
Второе: Какой глубокий смысл индекса у таблиц discount_tranzaction*
если количество записей индекса равно количеству записей в таблице. Если для сортировки то насколько я понимаю сортируется результат в админке. И бесполезно использовать индексацию поля даты так как это почти уникальная запись а в связке с другими полями абсолютно уникальная. Короче грохнул я эти индексы, создал свой, выгода: выбока идет быстрее, инсерты идут быстрее так как обновляется индекс по 1 полю а у тройной, и размер таблицы уменьшился почти в два раза что привело к дополнительному росту быстродействия из-за уменьшения дисковых операций.
Третье: Таблица dhs.session.log была без индексов, добавил индекс выборка инфрмации по сессиям стала делатся за несколько секунд, вместо минут.
если количество записей индекса равно количеству записей в таблице. Если для сортировки то насколько я понимаю сортируется результат в админке. И бесполезно использовать индексацию поля даты так как это почти уникальная запись а в связке с другими полями абсолютно уникальная. Короче грохнул я эти индексы, создал свой, выгода: выбока идет быстрее, инсерты идут быстрее так как обновляется индекс по 1 полю а у тройной, и размер таблицы уменьшился почти в два раза что привело к дополнительному росту быстродействия из-за уменьшения дисковых операций.
Третье: Таблица dhs.session.log была без индексов, добавил индекс выборка инфрмации по сессиям стала делатся за несколько секунд, вместо минут.
По поводу п. 1: вообще-то, это не равносильные запросы, но я согласен, т. к. смысла LEFT-Join-ить нету, потому что когда ищем пользователей с некоторым ТП (1) подразумеваем, что у них уже есть некий ТП --> Можно забить на пары user<>tariff с tariff=NULL и (2) т. к. есть тариф, то есть лиц. счет, к которому он привязан. Поэтому s/LEFT/INNER/ можно спокойно делать.
UTM5/FreeBSD 5.3/MySQL 4.1/ipcad
А зачем? Вы же уже купили биллинг и если у вас что-то плохо работает - это лишний повод приобрести техподдержку (в общем случае). А у тех кто его только собирается приобрести наврядли столько пользователей, чтобы заметить недостатки отсутствия оптимизацииMagnum72 писал(а):Когда будем оптимизировать движок биллинга?
А не расскажешь что именно грохнул и что добавил?Magnum72 писал(а): Короче грохнул я эти индексы, создал свой, выгода: выбока идет быстрее, инсерты идут быстрее так как обновляется индекс по 1 полю а у тройной, и размер таблицы уменьшился почти в два раза что привело к дополнительному росту быстродействия из-за уменьшения дисковых операций.
Кстати, я тоже поколдовал над табличками *_service_links, у меня теперь поиск по ID связки и IP адресу на порядок быстрее работает
