Структура MySQL-базы — как лучше?

Shtogrin, Про индексы понятно, а много или мало 30% - это можно решать в частном порядке (но три джойна - это уже вдвое медленнее и может оказаться критичным моментом), как и остальные вещи касаемо архитектуры. Вариантов много.

Я бы поспорил . мы краш-тесты делали:

3 запроса в секунду с 20 машин одновременно. Работала 3 дня-ночи подряд.

Ни одного коллапса, сервер был двух процессорный, загрузка - 40-50 проц.

Что делалось:

Открывалась выборочная страничка, потом прыгали по разделам сайта и после получение файла и принятие файла(причем специально были сделаны битые файлы)

размер файлов колебался от 500 байт до 1.5 метра

• Все логировалось.
• Все шаблоны для портала были в лайте.
• Файлы тоже были в лайте(для загрузки и для выгрузки).

Я разделил все базы:

• для шаблонов
• для статитстики
• для файлов

Результат:

• Размер лог файла после работы - около 1.5 гига
• Размер базы файловой - ок. 4 гигов
• Размер базы для шаблонов не изменился

Время доступа к порталу варировалось от 0.7 до 3х секунд.

Время обработки примерно было 1.5 секунд.

П.С.

Главное с индексами не перемудрить (нарпимер, в базе статистики я вообще индексов не делал, так как там просто инсерт)

AlienZzzz, подскажите пожалуйста что почитать можно по оптимизации БД, желательно на русском.

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

Спасибо.

ZeHer, www.sql.ru

Немного синтетический тест. Но картина была бы нагляднее в сравнении с MySQL.

синтетический это как ?

__

После перевода с мускула - скорость доступа на пиках понизилась с 3 сек до 1.5

Не могли бы вы уточнить причину, очень интересно.

Спасибо

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

-каждый индекс элементарно занимает место на диске;

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

Также можно использовать insert delayed, low priority и т.д. Но нужно понимать как сие работает - это хорошо в документации описано.

Таким образом, если в той же статистике есть временная таблица, в которую идут одни вставки, а чтение идет просто вподряд с удалением обработанного - то индекс и не нужен (но нужно периодически запускать optimize table 🚬 ).

Причину чего ?

если вы про причину, почему я снес индексы, потому что

1. при большом объеме данных это сильно замедляет втсавку.

2. таблица лочилась(LOCK), и все остальные процесы ждали(время доступа существенно возрастало)

3. там они не нужны,так как в статистику нужно быо залезать не так часто.

И, кстати, полезно смотреть explain - иногда там можно много интересного увидеть и про использование индексов в том числе.