Владимир, спасибо вам огромное, за то, что дарите свет знаний нам, тёмным. Мне 40, переквалифицировался в программисты и учусь по вашим видео!

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

Смотрел эти Мини-лекции ещё когда учился в школе, вот уже два года как выпустился из университета. В универе благодаря Владимиру экономил своё время перед экзаменами. Теперь работаю и иногда освежаю информацию в памяти. Спасибо вам!

Спасибо, за достоверную информацию, всегда бьете прямо в цель и суть вопроса!

Даже спустя столько времени актуально, спасибо! Хорошо объяснили, буду иметь ввиду и проверю все ваши советы

Пожалуй лучшее видео о том, как и когда лучше использовать индексы. Благодарю!

Расскажи пожалуйста про составные индексы и про очерёдность столбцов, хотелось бы ещё видеть как писать код

Это супер! Очень помогли при архитектуре БД и составлении схем в ORM, спасибо!

Молодец! Спасибо, за материал.

Супер! Всё очень доходчиво, большое Вам спасибо!

Спасибо Владимир!

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

Спасибо! Вы очень хорошо объясняете!

Отлично все объяснил! Спасибо)

Спасибо, уложил мне и другим все в голове, от вас бы еще сравнение разных баз данных для разных задач )

Спасибо! Хорошо объяснили. Будут ли видео о проектировании баз данных? Какие-то рекомендации на эту тему? Нормализации таблиц, денормализации, ведь это тоже с производительностью тесно свзяано, например много JOIN'ов не есть хорошо и.т.д.

Спасибо за лекцию. Очень помогли

Отличное видео! Большое спасибо

огромная спасибо! отличное объяснение! долго в голове не укладывалось

Володя спасибо! Хорошо рассказываешь. Расскажи какие типы индексов использовать в каких случаях.

Коротко и по делу. Очень годно.

Спасибо!!!

Спасибо!

Большое спасибо за подробное разъяснение, а то я сам чуть все индексами не сделал ;)

Спасибо, очень информативно

спасибо за полезную информацию

Отличное видео! Спасибо

Спасибо дядька! Полезно.

Супер! Чуть подробнее интересно было бы услышать про WHERE с операторами сравнения "больше" и "меньше".

урок пушка, спасибо!

спасибо, давно искал такое простое объяснение

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

Спасибо очень наглядно, подскажи пожалуйста если делать инсерт новых строк то индекс на них индекс автоматом встанет? И ещё вопрос апдейт быстрее чем перезапись всей таблицы (более 10млн строк) ?

Спасибо.

Володя спасибо, я все понял понял)

Отлично спасибо ! Частные уроки по скайпу проводите ?

Автор, немного серьезнее отнестись к тому, что говорите. Вы делаете акцент на том, что Having выполняется после в конце, но это не аргумент, т.к. Order by выполняется вообще последним, после Select, перед которым выполняется Having. И то что "для select нужно сдавать индексы, а для update нет" - это конечно тоже странное утверждение, учитывая что update - в используемом контексте это и select также, со своими возможными предикатами, для которых тоже используется индекс.

Мужик !

Лучший!

Мне пока кажется, что для Join on в первую очередь нужно делать индекс. приоритетнее чем where.

Добрый день! Команда CREATE MATERIALIZED VIEW AS SELECT вставляя данные в мат. витрину под капотом использует INSERT.? По сути она вставляет данные., значит это INSERT?

Гений!

Здравствуйте! Не знал, что индексы так же помогают в сортировке данных.. Скажите вот у меня в таблице есть поле, которое принимает id родительского комментария и соответственно может повторятся, и тут возник вопрос стоит ли его индексировать? просто всегда думал, что индекс должен быть уникальным. Спасибо.

@VladimirMozhenkov

8 жыл бұрын

+Moon- -Ster Вы-же будете его использовать для JOIN-ов, так что скорее всего стоит.

@VladimirMozhenkov

8 жыл бұрын

+Moon- -Ster Уникальность не обязательна ))

👍🏻👍🏻👍🏻

Что поменялось спустя 5 лет? Советы индексирования остались те же? Или есть какие-то изменения?

👍

Подскаэите пжлста есть ли смысл создавать индекс для таблицы где всего две колонки форен кей

Володя я тебя люблю

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

а если я ищу не через оператор = ,а через оператор IN и поиск у меня происходит по нескольким полям IN(поле1, поле2)?

@tanataytkaliyev5206

2 жыл бұрын

А аналогом чего в sql является in? Ответив на этот вопрос, получите ответ на изначальный

Вопрос: а если колонка часто используется в секции WHERE, но при этом так же часто подвергается UPDATE'у?

Здравствуйте!Вопрос такой , у меня поле при инсерте записи изначально null но потом апдейтится только один раз. Данное поле участвует в join.Стоит его индексировать ?

@dmitriist255

3 жыл бұрын

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

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

Вроды бы для запросов с like вида "%something", "something%" и "%something%" index будет полезен

@tarasbmal

5 жыл бұрын

Однозначно, коллега! )

Топ

Спасибо !!! Поставил индексы и скрипт стал выполнятся не 750 сек, а 10 сек )

@chuckchuck1090

3 жыл бұрын

@unk unk ну мб там база на 60млн записей))) У меня на работе есть и больше

Добрый день , можно узнать почему на этом видео стд лицензия ?

@VladimirMozhenkov

8 жыл бұрын

+Иван Иванович Исправил. Если заметите такое ещё, дайте знать.

Комментарий для продвижения видео

если update с блоком where, то индекс будет задействован и тоже поможет)

ээээ... это сколько кже лет посгри индексирует и лайк, и сравнения в зависимости от индекса?? (b tree)

почему сравнение больше/меньше менее эффективно чем равенство？

а если в ON есть операция >?

При update/insert ты едва ли что-то теряешь при использовании индекса. Потеря константна. А вот при select ты очень много экономишь при использовании индекса. Экономия зависит от величины базы. И ради солнца, ставьте индексы на внешний ключ, всегда) История из жизни: выполнялась по cron'у раз в минуту одна процедура. Ну секунд 20-30 занимала, вроде норм. Шли месяца... Данных становилось все больше, и больше. Стало так много, что эта процедура стала занимать больше минуты. В итоге процессы не успевали закончитьься, как появлялись такие же новые. Больше процессов, меньше ресурсов - еще медленнее процедуры - еще больше процедур. Ну вы наверное уже поняли к чему я клоню. Сервер упал))) Сервер пролежал 7 часов! Пока все опомнились, пока сообщили нужным людям, а те другим людям, а те программистам, пока программист подключился, перезагрузил сервер, все поднял, обнаружил проблему, поправил... Так что не ленитесь ставить индексы!) Для сравнения, после добавления одного единственного индекса процедура стала занимать ~8 секунд! А там записей было не так много, немногим больше миллиона.

@keydon5661

4 жыл бұрын

Jerry Green так ваша история не про индексы, а про то что надо использовать flock, если команду стоит запускать в одном экземпляре

Зачем вы учите тому, в чём не разбираетесь? К примеру в постгрес, запросы where > =

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

Ролик конечно же полезный, но в нём не рассматриваются ситуации использования ORM, например Hibernate.

@user-xk8le4dv5n

8 жыл бұрын

+Beta Вот про эти запросы и следует поговорить. Ведь именно от них зависит, стоит или не стоит создавать индекс.

@user-xk8le4dv5n

8 жыл бұрын

***** В ролике говорится про запросы, явно формируемые программистом. Как это делает ORM неочевидно.

@stMrJerry

7 жыл бұрын

ну так это уже твоя задача знать какие запросы делает твоя ORM тем более что обычно ORM позволяет привести любое выражение к sql-запросу через специальный метод

@user-xk8le4dv5n

7 жыл бұрын

Jerry Green ORM для того и создавались, чтобы не заморачиваться SQL запросами.

@stMrJerry

7 жыл бұрын

שלום עליכם ну так и не заморачивайся. Ваще забей на индексы, запросы, на все. Иди работай бухгалтером)

Почему для like не нужен индекс? Наверно речь идёт о неопределенном начале строки? Like % ... % Для like ... % индекс ускорит работу

Не очевидно, почему вдруг операторы сравнения исключают индексирование. B-tree целиком построено на сравнениях. Ощущение, что лектор не очень хорошо понимает, как устроены индексы.

@VladimirMozhenkov

2 жыл бұрын

Не очевидно, потому что не исключают.

@GLOBALeVGENIUS

2 жыл бұрын

@@VladimirMozhenkov в ролике сказано, что идексы похдходят только для случаев, где у нас сравнение на равенство, но не на больше / меньше

Володя, я думаю, тебе нужно подтянуть теоретическую часть, исходя из досмотренного видео до 5:25 :) Это утверждение насчет того, что создавайте индексы только по тем полям, которые будут находиться в фильтре - морально устарело. Во-первых: все мы знаем, что индекс хорош при фильтрации (чтобы план выполнения не делал table scan, перебирая и блокируя записи, а делал seek, что к блокировке не приводит, и сразу имеется дерево для поиска ) Но он якобы плох при изменении данных, поскольку изменение данных будет выполняться медленно из-за изменения индексов. Значит, это может быть и было актуально, но лет 10 назад, когда были медленные диски, и RAM ужасно дорогая. Сейчас вычислительные можности позволяют, а многие теоретики даже рекомендуют (а я это на своей шкуре прочувствовал) ставить индексы на _все_ поля. Все - по шаблону, поскольку за нас уже все придумано: 1) В каждой таблице должно быть поле суррогатного первичного ключа (ID, даже если сейчас и не нужно) 2) В каждой таблице каждое поле должно быть проиндексировано - по индексу на каждое поле 3) Очень желательно иметь натуральный (даже составной) уникальный индекс, который служит для выделения сущности, и для поддержания обеспечения целостности. И забудем мы надолго овертаймы, падения производительности при очередном билде и т.д.: сегодня по этому полю where не ставится, а завтра - оно и попадет в фильтр. И че теперь - включать какой-нибудь tuning advisor чтобы он нам подсказал, где надо ставить индекс? А про то, что индекс на like не нужен - это неправда, которую две недели назад фиксил индексами (ечли чо - старючий MS SQL 2005) :)

@stMrJerry

7 жыл бұрын

Тоже не понял прикола. Вроде бы sql запросы на то и сделаны, чтобы еще до непосредственно получения данных описать какие данные тебе нужны)

@CoricComPlus

7 жыл бұрын

Jerry Green sql - это структурированный язык запросов данных, а не описыватель каких-то метаданных :) да и select * from blablabla (очень плохой запрос) - "какие данные нужны" все зависит от источника данных, а если его расширяют - то изменится

@stMrJerry

7 жыл бұрын

A. Z. ну а что есть "язык запросов"? Ты описываешь что ты запрашиваешь - после чего это получаешь. Не наоборот.

@CoricComPlus

7 жыл бұрын

Jerry Green Как-то безграмотно пишешь. Я не описываю, _что_ я хочу получить. Я описываю, _как_ я хочу получить. Посредством структуры запросов. Мы не говорим про структуры данных :)

@roman8745

4 жыл бұрын

странно что никто за 3 года не написал не придерживаться мнения изложенном в этом комментарии. уже давно есть люди которые специализируются по database performance tuning и с ваших слов они уже как 10 лет никому не нужны так как можно установить индекс на каждый столбец отдельно. открою секрет но seek не всегда выполняется быстрее чем table scan (в некоторых случаях он лучше и выполняется намного быстрее), не говоря уже о композитных индексах которые также с ваших слов не нужны. сравните перфоманс insert/update таблицы с множеством атрибутов и данных с установленным индексом на каждый. при каждом изменении запроса и требований изменяется структура таблицы если это нужно,

Подытожу. Программист сам должен прикинуть что, как часто и зачем используется, вычислить в мозгу примерный баланс затрат времени на запись/чтение и выродить. Современные базы данных настолько интеллектуальны, что сами такого не могут. Это как дать им инструкцию вылить ведро воды на грядку. Это нужно найти ведро, найти где его наполнить водой, налить туда воды, принести к грядке и дать современной СУБД вылить воды. Т.е. 99,987259% трудозатрат выполнит все равно человек. СУБД гордо выльет воду! Программистов надо имхо убивать. А то их бесконтрольтное размножение приводит к распространению всяких опусов типа виндовс. Или линукс. Да почти всего. Си++ хоть вспомните. Или яву. Скрипт. В первую очередь конечно надо убивать сиобразов. Вот это пздц багогенераторы в сотой степени! (Любители бл..ть краткости, су..0 сестры таланта.) Генераторы "надежных" решений основанных на иерархических структурах кое как налепленного эклектичного говна на еще большем говне. Авианосцы пристроенные к дачному туалету.

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

Спасибо!

Вроды бы для запросов с like вида "%something", "something%" и "%something%" index будет полезен

@VladimirMozhenkov

8 жыл бұрын

+Абакумов Андрей Здесь уже, на сколько я знаю, зависит от конкретной базы данных. Многие и такое могут оптимизировать. Например они могут использовать бинарные (или другие) деревья для ускорения поиска... и тд. Но вот например если вы уже используете регулярное выражение, тут я не знаю баз данных которые вам помогут.

Спасибо!

Спасибо!