1) Если во внешней бд,например, в 1с, гуиды. То на сайте должны быть гуиды в кач-ве первичного ключа. Или же сделать ид автоинкрементом? Дело в том минусы гуидов - это долгая вставка индекса первичного ключа.
2) Если нужна сортировка и группирование по нескольким таблицам. В этом случае мы делаем денормализацию, и добавляем столбцы из других таблиц в одну таблицу. Верно?
Нужно сделать денормализацию, провести (сортируемые и группируемые поля(из других таблиц) добавить в основную,и на нее добавить индекс). Причем сортируемые и группируемые поля добавить в самый конец индекса. Правильно?
Очень нужен хороший курс по оптимизации бд, или книги. именно по индексам. читала , читала...официальная документация сухая, не свовсем понятно, некоторые моменты. может после нескольких заходов поймешь( но пока не дошло).
Вообще непонятно, при чём тут теория MySQL (а по большому счёту - что это вообще такое).
Мешать в кучу сайт и сервер БД бессмысленно.
"долгая вставка индекса первичного ключа" - это как бы сказки. Или, если на самом деле тормозит - то весьма вряд ли по вине MySQL, там же посредников не счесть.
Сортировка и группировка выполняется не по таблицам, а по выражениям. Но это к слову.
Денормализация? она-то тут каким боком?
"сортируемые и группируемые поля добавить в самый конец индекса" ?? Какого индекса-то? не говоря уж о том, что индексов по выражениям, включающим поля нескольких таблиц - не существует. Не только в MySQL - вообще в любой СУБД.
не свовсем понятно, некоторые моменты
Ну так и задавайте вопросы по ним. Один вопрос - один непонятный момент.
"долгая вставка индекса первичного ключа" - это как бы сказки. Или, если на самом деле тормозит - то весьма вряд ли по вине MySQL, там же посредников не счесть
.
Тормоза нет, просто уточняю . я прочитала об этом в книге https://www.oreilly.com/library/view/high-performa... , что гуид нежелательно делать, а нужно ид(автоинкремен -целое число). А исходя с Ваших слов ,то есть можно гуид сделать первичным ключом в моем случае, если импортируешь с 1с.
или же нужно сделать в качестве первичного ключа автоинкремен целое число?
Сортировка и группировка выполняется не по таблицам, а по выражениям. Но это к слову.
В этом случае мы делаем денормализацию, и добавляем столбцы из других таблиц в одну таблицу. Верно?
"сортируемые и группируемые поля добавить в самый конец индекса" ?? Какого индекса-то? не говоря уж о том, что индексов по выражениям, включающим поля нескольких таблиц - не существует. Не только в MySQL - вообще в любой СУБД.
я знаю, поэтому нужно из другой таблицы столбцы добавить в нужную таблицу, чтобы создать индекс. В этом случае мы делаем денормализацию, и добавляем столбцы из других таблиц в одну таблицу.
Rsa97, спасибо БОЛЬШОЕ за подсказку. То есть можно не добавлять ид в каестве первичного ключа, а гуид перенести в поле "внешний код", и тоже на него индекс. С другой стороны судя по скудной инфе, которую я прочитала, что простые ид плохи при реплике.
Повторюсь, у меня скудная инфа, и знании не хватает. В любом случае спасибо за подсказку.
Я все время импортирую с 1с, не подскажете затраты на перевод гуида в бинарное представление какие будут?
Выбор таких гуидов, не спорю, будет быстро.
Hfnas, Затраты минимальные. Начиная с MySQL 8.0 есть специальные функции UUID_TO_BIN() и BIN_TO_UUID().
В старых версиях UUID_TO_BIN можно заменить двумя функцииями, если гуид записан с дефисами. UNHEX(REPLACE(:guid, '-', '')) - на выходе BINARY(16).
1. У вас такие объемы и нагрузки что это становится критичным? Даже если вы сделаете первичный ключ интом - все равно индекс (и скорее всего уникальный) по уидам вам нужно будет строить.
2. Джойны прекрасно поддаются агрегации и сортировке. Опять же все зависит от объемов и нагрузок. Денормализация нужна там где сотни тысяч-миллионы и более записей в таблице. Вот тогда денормализация начинает играть роль в качестве средства оптимизации. Сортируемые и группируемые поля совершенно необязательно должны быть в индексе.
Михаил, благодарю за ваше внимание! 1 вопрос отпал. Спасибо Вам большое! Просто в книге https://www.oreilly.com/library/view/high-performa... , правда 2 издания указано, что гуиды нежелательно использовать в качестве первичного ключа, из-за трудности вставки (индекс изначально отсортирован), то есть при каждом добавлении приходится перестраивать индекс.
Даже, если я добавлю первичный ключ интом, мне придется добавить индекс уже по полю гуид(добавление индекса тоже влияет на вставку записи в бд). Итог, что лучше 2 индекса уникальных или один? Конечно, один. Спасибо Вам большое! А что скажете по поводу бинарного представления uuid? правда, придется при вставке гуида переводить в бинарное представление, затраты на такую операцию окупаются? Да, не спорю, при селекте будет отлично выбираться. Спасибо Rsa97 за мысль перевода гуидов в бинарное представление.
2) Я часто делаю сортировку и группировку по нескольким полям из разных таблиц (минимум из трех), запрос пока вроде быстро идет(делаю EXPLAIN ANALYZE, смотрю на (actual time=0.160..0.163 ), но мне не нравится filesort (если делаешь explain)., в тоже числе по агрегирующим функциям , такими как сумма
Мы же должны избавиться от запросов типа where, all, memory, filesort,
Самый лучший запрос, наверное то, который использует индекс. Поэтому я добавляю из других таблиц поля в одну, чтобы по нему добавить индекс(2 поля из одной таблицы, одно поле из другой таблицы). Но, стоимость вставки не оправдана, если делать вставку записи через сущность. Поэтому у меня возник таколй вопрос. В доках написано индекс нужен для полей where, order by, group by. Может, я что-то не уловила, подскажите, пожалуйста, что поискать.
и еще у меня есть на сайте функция сортировка по каждому столбцу, естественно по каждому полю я не добавляю индекс, так как это затратно при вставке записи. Правда, не знаю, верный у меня подход? Но , бд будет расти постоянно.
Например, есть таблицы `products`, `products_group` . Для таблицы `products` указан столбец количество на складе. Далее для таблицы `products_group` нужно указать количество товаров по группам, в этом случае делают денормализацию?
Hfnas, еще раз скажу: пока у вас не миллионы записей - пользуйтесь JOIN, без денормализации. С денормализацией вы хлебнете проблем полной ложкой, в первую очередь с рассинхронизацией данных.
Пока вас устраивает скорость работы запросов - забейте на FILESORT.
Хотите - проведите нагрузочное тестирование с объемом данных в 10-100 раз больше чем сейчас, убедитесь что в перспективе там ничего страшного не происходит с производительностью.
Преждевременная оптимизация - зло.
Простой
