Многие слышали про индексы в базах данных, но обсуждение по поводу когда стоит создавать эти индексы встречается в просторах интернета не так уж и часто. Этот урок как раз об этом.
Мужииииииик, ты вообще крут, большой большой большой респект тебе, где ты раньше был, я ещё раз и гораздо лучше все это понял ))))) Ждём твоих видео ))))))
Смотрел эти Мини-лекции ещё когда учился в школе, вот уже два года как выпустился из университета. В универе благодаря Владимиру экономил своё время перед экзаменами. Теперь работаю и иногда освежаю информацию в памяти. Спасибо вам!
супер видео! благодарю, кратко понятно. вопросы задают на собеседование. Я так понял, надо все запросы из программы собрать, после проанализировать какие поля в where используются и создать по ним индекс.
Спасибо! Хорошо объяснили. Будут ли видео о проектировании баз данных? Какие-то рекомендации на эту тему? Нормализации таблиц, денормализации, ведь это тоже с производительностью тесно свзяано, например много JOIN'ов не есть хорошо и.т.д.
Автор, немного серьезнее отнестись к тому, что говорите. Вы делаете акцент на том, что Having выполняется после в конце, но это не аргумент, т.к. Order by выполняется вообще последним, после Select, перед которым выполняется Having. И то что "для select нужно сдавать индексы, а для update нет" - это конечно тоже странное утверждение, учитывая что update - в используемом контексте это и select также, со своими возможными предикатами, для которых тоже используется индекс.
При update/insert ты едва ли что-то теряешь при использовании индекса. Потеря константна. А вот при select ты очень много экономишь при использовании индекса. Экономия зависит от величины базы. И ради солнца, ставьте индексы на внешний ключ, всегда) История из жизни: выполнялась по cron'у раз в минуту одна процедура. Ну секунд 20-30 занимала, вроде норм. Шли месяца... Данных становилось все больше, и больше. Стало так много, что эта процедура стала занимать больше минуты. В итоге процессы не успевали закончитьься, как появлялись такие же новые. Больше процессов, меньше ресурсов - еще медленнее процедуры - еще больше процедур. Ну вы наверное уже поняли к чему я клоню. Сервер упал))) Сервер пролежал 7 часов! Пока все опомнились, пока сообщили нужным людям, а те другим людям, а те программистам, пока программист подключился, перезагрузил сервер, все поднял, обнаружил проблему, поправил... Так что не ленитесь ставить индексы!) Для сравнения, после добавления одного единственного индекса процедура стала занимать ~8 секунд! А там записей было не так много, немногим больше миллиона.
Как общая теория пойдет, вы знаете, что бывают различные алгоритмы индексов, каждый под свою задачу. Так что важно было упомянуть с какими данными приходится работать
Спасибо очень наглядно, подскажи пожалуйста если делать инсерт новых строк то индекс на них индекс автоматом встанет? И ещё вопрос апдейт быстрее чем перезапись всей таблицы (более 10млн строк) ?
Добрый день! Команда CREATE MATERIALIZED VIEW AS SELECT вставляя данные в мат. витрину под капотом использует INSERT.? По сути она вставляет данные., значит это INSERT?
Объясните пожалуйста, для чего нужны связи, отношения. Не совсем пойму логическое для чено они нужны. Весь интернет заполнен этими связями а вот для чего они нужны не совсем понятно, никто не объясняет. Объясните пожалуйста
теория- это хорошо. хорошо объяснённая теория - ещё лучше. но без практики некоторый туман в понимании остаётся. прям, не хватает практического обучения SQL с нуля.
Здравствуйте!Вопрос такой , у меня поле при инсерте записи изначально null но потом апдейтится только один раз. Данное поле участвует в join.Стоит его индексировать ?
Не очевидно, почему вдруг операторы сравнения исключают индексирование. B-tree целиком построено на сравнениях. Ощущение, что лектор не очень хорошо понимает, как устроены индексы.
ну так это уже твоя задача знать какие запросы делает твоя ORM тем более что обычно ORM позволяет привести любое выражение к sql-запросу через специальный метод
Подытожу. Программист сам должен прикинуть что, как часто и зачем используется, вычислить в мозгу примерный баланс затрат времени на запись/чтение и выродить. Современные базы данных настолько интеллектуальны, что сами такого не могут. Это как дать им инструкцию вылить ведро воды на грядку. Это нужно найти ведро, найти где его наполнить водой, налить туда воды, принести к грядке и дать современной СУБД вылить воды. Т.е. 99,987259% трудозатрат выполнит все равно человек. СУБД гордо выльет воду! Программистов надо имхо убивать. А то их бесконтрольтное размножение приводит к распространению всяких опусов типа виндовс. Или линукс. Да почти всего. Си++ хоть вспомните. Или яву. Скрипт. В первую очередь конечно надо убивать сиобразов. Вот это пздц багогенераторы в сотой степени! (Любители бл..ть краткости, су..0 сестры таланта.) Генераторы "надежных" решений основанных на иерархических структурах кое как налепленного эклектичного говна на еще большем говне. Авианосцы пристроенные к дачному туалету.
Володя, я думаю, тебе нужно подтянуть теоретическую часть, исходя из досмотренного видео до 5:25 :) Это утверждение насчет того, что создавайте индексы только по тем полям, которые будут находиться в фильтре - морально устарело. Во-первых: все мы знаем, что индекс хорош при фильтрации (чтобы план выполнения не делал table scan, перебирая и блокируя записи, а делал seek, что к блокировке не приводит, и сразу имеется дерево для поиска ) Но он якобы плох при изменении данных, поскольку изменение данных будет выполняться медленно из-за изменения индексов. Значит, это может быть и было актуально, но лет 10 назад, когда были медленные диски, и RAM ужасно дорогая. Сейчас вычислительные можности позволяют, а многие теоретики даже рекомендуют (а я это на своей шкуре прочувствовал) ставить индексы на _все_ поля. Все - по шаблону, поскольку за нас уже все придумано: 1) В каждой таблице должно быть поле суррогатного первичного ключа (ID, даже если сейчас и не нужно) 2) В каждой таблице каждое поле должно быть проиндексировано - по индексу на каждое поле 3) Очень желательно иметь натуральный (даже составной) уникальный индекс, который служит для выделения сущности, и для поддержания обеспечения целостности. И забудем мы надолго овертаймы, падения производительности при очередном билде и т.д.: сегодня по этому полю where не ставится, а завтра - оно и попадет в фильтр. И че теперь - включать какой-нибудь tuning advisor чтобы он нам подсказал, где надо ставить индекс? А про то, что индекс на like не нужен - это неправда, которую две недели назад фиксил индексами (ечли чо - старючий MS SQL 2005) :)
Jerry Green sql - это структурированный язык запросов данных, а не описыватель каких-то метаданных :) да и select * from blablabla (очень плохой запрос) - "какие данные нужны" все зависит от источника данных, а если его расширяют - то изменится
Jerry Green Как-то безграмотно пишешь. Я не описываю, _что_ я хочу получить. Я описываю, _как_ я хочу получить. Посредством структуры запросов. Мы не говорим про структуры данных :)
странно что никто за 3 года не написал не придерживаться мнения изложенном в этом комментарии. уже давно есть люди которые специализируются по database performance tuning и с ваших слов они уже как 10 лет никому не нужны так как можно установить индекс на каждый столбец отдельно. открою секрет но seek не всегда выполняется быстрее чем table scan (в некоторых случаях он лучше и выполняется намного быстрее), не говоря уже о композитных индексах которые также с ваших слов не нужны. сравните перфоманс insert/update таблицы с множеством атрибутов и данных с установленным индексом на каждый. при каждом изменении запроса и требований изменяется структура таблицы если это нужно,
+Абакумов Андрей Здесь уже, на сколько я знаю, зависит от конкретной базы данных. Многие и такое могут оптимизировать. Например они могут использовать бинарные (или другие) деревья для ускорения поиска... и тд. Но вот например если вы уже используете регулярное выражение, тут я не знаю баз данных которые вам помогут.
Здравствуйте! Не знал, что индексы так же помогают в сортировке данных.. Скажите вот у меня в таблице есть поле, которое принимает id родительского комментария и соответственно может повторятся, и тут возник вопрос стоит ли его индексировать? просто всегда думал, что индекс должен быть уникальным. Спасибо.
Владимир, спасибо вам огромное, за то, что дарите свет знаний нам, тёмным. Мне 40, переквалифицировался в программисты и учусь по вашим видео!
Мужииииииик, ты вообще крут, большой большой большой респект тебе, где ты раньше был, я ещё раз и гораздо лучше все это понял ))))) Ждём твоих видео ))))))
Смотрел эти Мини-лекции ещё когда учился в школе, вот уже два года как выпустился из университета. В универе благодаря Владимиру экономил своё время перед экзаменами. Теперь работаю и иногда освежаю информацию в памяти.
Спасибо вам!
Пожалуй лучшее видео о том, как и когда лучше использовать индексы. Благодарю!
Спасибо, уложил мне и другим все в голове, от вас бы еще сравнение разных баз данных для разных задач )
Большое спасибо за подробное разъяснение, а то я сам чуть все индексами не сделал ;)
супер видео! благодарю, кратко понятно. вопросы задают на собеседование. Я так понял, надо все запросы из программы собрать, после проанализировать какие поля в where используются и создать по ним индекс.
Расскажи пожалуйста про составные индексы и про очерёдность столбцов, хотелось бы ещё видеть как писать код
Это супер! Очень помогли при архитектуре БД и составлении схем в ORM, спасибо!
Спасибо Владимир!
Супер!
Чуть подробнее интересно было бы услышать про WHERE с операторами сравнения "больше" и "меньше".
Ничего нового не узнал, имею богатый опыт, но хочу отметить очень качественную, доходчивую и лёгкую к восприятию подачу материала.
Спасибо! Хорошо объяснили. Будут ли видео о проектировании баз данных? Какие-то рекомендации на эту тему? Нормализации таблиц, денормализации, ведь это тоже с производительностью тесно свзяано, например много JOIN'ов не есть хорошо и.т.д.
Коротко и по делу. Очень годно.
Супер! Всё очень доходчиво, большое Вам спасибо!
Молодец! Спасибо, за материал.
огромная спасибо! отличное объяснение! долго в голове не укладывалось
Спасибо!
Спасибо! Вы очень хорошо объясняете!
Отлично все объяснил! Спасибо)
спасибо за полезную информацию
Спасибо за лекцию. Очень помогли
Автор, немного серьезнее отнестись к тому, что говорите. Вы делаете акцент на том, что Having выполняется после в конце, но это не аргумент, т.к. Order by выполняется вообще последним, после Select, перед которым выполняется Having.
И то что "для select нужно сдавать индексы, а для update нет" - это конечно тоже странное утверждение, учитывая что update - в используемом контексте это и select также, со своими возможными предикатами, для которых тоже используется индекс.
Отличное видео! Большое спасибо
При update/insert ты едва ли что-то теряешь при использовании индекса. Потеря константна.
А вот при select ты очень много экономишь при использовании индекса. Экономия зависит от величины базы.
И ради солнца, ставьте индексы на внешний ключ, всегда)
История из жизни: выполнялась по cron'у раз в минуту одна процедура. Ну секунд 20-30 занимала, вроде норм. Шли месяца... Данных становилось все больше, и больше. Стало так много, что эта процедура стала занимать больше минуты. В итоге процессы не успевали закончитьься, как появлялись такие же новые. Больше процессов, меньше ресурсов - еще медленнее процедуры - еще больше процедур. Ну вы наверное уже поняли к чему я клоню. Сервер упал)))
Сервер пролежал 7 часов! Пока все опомнились, пока сообщили нужным людям, а те другим людям, а те программистам, пока программист подключился, перезагрузил сервер, все поднял, обнаружил проблему, поправил... Так что не ленитесь ставить индексы!)
Для сравнения, после добавления одного единственного индекса процедура стала занимать ~8 секунд! А там записей было не так много, немногим больше миллиона.
Jerry Green так ваша история не про индексы, а про то что надо использовать flock, если команду стоит запускать в одном экземпляре
Лучший!
Вопрос: а если колонка часто используется в секции WHERE, но при этом так же часто подвергается UPDATE'у?
урок пушка, спасибо!
Володя спасибо! Хорошо рассказываешь. Расскажи какие типы индексов использовать в каких случаях.
Спасибо, очень информативно
Как общая теория пойдет, вы знаете, что бывают различные алгоритмы индексов, каждый под свою задачу. Так что важно было упомянуть с какими данными приходится работать
👍
Гений!
Отлично спасибо ! Частные уроки по скайпу проводите ?
если update с блоком where, то индекс будет задействован и тоже поможет)
Спасибо.
Вроды бы для запросов с like вида "%something", "something%" и "%something%" index будет полезен
Однозначно, коллега! )
Мне пока кажется, что для Join on в первую очередь нужно делать индекс. приоритетнее чем where.
Подскаэите пжлста есть ли смысл создавать индекс для таблицы где всего две колонки форен кей
Зачем вы учите тому, в чём не разбираетесь? К примеру в постгрес, запросы where > < >=
а если я ищу не через оператор = ,а через оператор IN и поиск у меня происходит по нескольким полям IN(поле1, поле2)?
А аналогом чего в sql является in? Ответив на этот вопрос, получите ответ на изначальный
Спасибо очень наглядно, подскажи пожалуйста если делать инсерт новых строк то индекс на них индекс автоматом встанет? И ещё вопрос апдейт быстрее чем перезапись всей таблицы (более 10млн строк) ?
Что поменялось спустя 5 лет? Советы индексирования остались те же? Или есть какие-то изменения?
а если в ON есть операция >?
Володя я тебя люблю
Добрый день!
Команда CREATE MATERIALIZED VIEW AS SELECT вставляя данные в мат. витрину под капотом использует INSERT.? По сути она вставляет данные., значит это INSERT?
Объясните пожалуйста, для чего нужны связи, отношения. Не совсем пойму логическое для чено они нужны. Весь интернет заполнен этими связями а вот для чего они нужны не совсем понятно, никто не объясняет. Объясните пожалуйста
👍🏻👍🏻👍🏻
почему сравнение больше/меньше менее эффективно чем равенство？
ээээ... это сколько кже лет посгри индексирует и лайк, и сравнения в зависимости от индекса?? (b tree)
теория- это хорошо. хорошо объяснённая теория - ещё лучше. но без практики некоторый туман в понимании остаётся. прям, не хватает практического обучения SQL с нуля.
Здравствуйте!Вопрос такой , у меня поле при инсерте записи изначально null но потом апдейтится только один раз. Данное поле участвует в join.Стоит его индексировать ?
Определенно да, если после апдейта не будет новых, а только участие этого поля в запросах на выборку данных (в т.ч. при джойнах).
Добрый день , можно узнать почему на этом видео стд лицензия ?
+Иван Иванович Исправил. Если заметите такое ещё, дайте знать.
Топ
Почему для like не нужен индекс? Наверно речь идёт о неопределенном начале строки? Like % ... %
Для like ... % индекс ускорит работу
Не очевидно, почему вдруг операторы сравнения исключают индексирование. B-tree целиком построено на сравнениях. Ощущение, что лектор не очень хорошо понимает, как устроены индексы.
Не очевидно, потому что не исключают.
@@VladimirMozhenkov в ролике сказано, что идексы похдходят только для случаев, где у нас сравнение на равенство, но не на больше / меньше
Ролик конечно же полезный, но в нём не рассматриваются ситуации использования ORM, например Hibernate.
+Beta Вот про эти запросы и следует поговорить. Ведь именно от них зависит, стоит или не стоит создавать индекс.
***** В ролике говорится про запросы, явно формируемые программистом. Как это делает ORM неочевидно.
ну так это уже твоя задача знать какие запросы делает твоя ORM
тем более что обычно ORM позволяет привести любое выражение к sql-запросу через специальный метод
Jerry Green
ORM для того и создавались, чтобы не заморачиваться SQL запросами.
שלום עליכם ну так и не заморачивайся. Ваще забей на индексы, запросы, на все. Иди работай бухгалтером)
Подытожу. Программист сам должен прикинуть что, как часто и зачем используется, вычислить в мозгу примерный баланс затрат времени на запись/чтение и выродить. Современные базы данных настолько интеллектуальны, что сами такого не могут. Это как дать им инструкцию вылить ведро воды на грядку. Это нужно найти ведро, найти где его наполнить водой, налить туда воды, принести к грядке и дать современной СУБД вылить воды.
Т.е. 99,987259% трудозатрат выполнит все равно человек. СУБД гордо выльет воду!
Программистов надо имхо убивать. А то их бесконтрольтное размножение приводит к распространению всяких опусов типа виндовс. Или линукс. Да почти всего. Си++ хоть вспомните. Или яву. Скрипт.
В первую очередь конечно надо убивать сиобразов. Вот это пздц багогенераторы в сотой степени! (Любители бл..ть краткости, су..0 сестры таланта.) Генераторы "надежных" решений основанных на иерархических структурах кое как налепленного эклектичного говна на еще большем говне. Авианосцы пристроенные к дачному туалету.
Володя, я думаю, тебе нужно подтянуть теоретическую часть, исходя из досмотренного видео до 5:25 :)
Это утверждение насчет того, что создавайте индексы только по тем полям, которые будут находиться в фильтре - морально устарело.
Во-первых: все мы знаем, что индекс хорош при фильтрации (чтобы план выполнения не делал table scan, перебирая и блокируя записи, а делал seek, что к блокировке не приводит, и сразу имеется дерево для поиска )
Но он якобы плох при изменении данных, поскольку изменение данных будет выполняться медленно из-за изменения индексов.
Значит, это может быть и было актуально, но лет 10 назад, когда были медленные диски, и RAM ужасно дорогая.
Сейчас вычислительные можности позволяют, а многие теоретики даже рекомендуют (а я это на своей шкуре прочувствовал) ставить индексы на _все_ поля.
Все - по шаблону, поскольку за нас уже все придумано:
1) В каждой таблице должно быть поле суррогатного первичного ключа (ID, даже если сейчас и не нужно)
2) В каждой таблице каждое поле должно быть проиндексировано - по индексу на каждое поле
3) Очень желательно иметь натуральный (даже составной) уникальный индекс, который служит для выделения сущности, и для поддержания обеспечения целостности.
И забудем мы надолго овертаймы, падения производительности при очередном билде и т.д.: сегодня по этому полю where не ставится, а завтра - оно и попадет в фильтр. И че теперь - включать какой-нибудь tuning advisor чтобы он нам подсказал, где надо ставить индекс?
А про то, что индекс на like не нужен - это неправда, которую две недели назад фиксил индексами (ечли чо - старючий MS SQL 2005) :)
Тоже не понял прикола. Вроде бы sql запросы на то и сделаны, чтобы еще до непосредственно получения данных описать какие данные тебе нужны)
Jerry Green sql - это структурированный язык запросов данных, а не описыватель каких-то метаданных :) да и select * from blablabla (очень плохой запрос) - "какие данные нужны" все зависит от источника данных, а если его расширяют - то изменится
A. Z. ну а что есть "язык запросов"? Ты описываешь что ты запрашиваешь - после чего это получаешь. Не наоборот.
Jerry Green Как-то безграмотно пишешь. Я не описываю, _что_ я хочу получить. Я описываю, _как_ я хочу получить. Посредством структуры запросов. Мы не говорим про структуры данных :)
странно что никто за 3 года не написал не придерживаться мнения изложенном в этом комментарии. уже давно есть люди которые специализируются по database performance tuning и с ваших слов они уже как 10 лет никому не нужны так как можно установить индекс на каждый столбец отдельно. открою секрет но seek не всегда выполняется быстрее чем table scan (в некоторых случаях он лучше и выполняется намного быстрее), не говоря уже о композитных индексах которые также с ваших слов не нужны. сравните перфоманс insert/update таблицы с множеством атрибутов и данных с установленным индексом на каждый.
при каждом изменении запроса и требований изменяется структура таблицы если это нужно,
Спасибо!!!
Комментарий для продвижения видео
Вроды бы для запросов с like вида "%something", "something%" и "%something%" index будет полезен
+Абакумов Андрей Здесь уже, на сколько я знаю, зависит от конкретной базы данных. Многие и такое могут оптимизировать. Например они могут использовать бинарные (или другие) деревья для ускорения поиска... и тд. Но вот например если вы уже используете регулярное выражение, тут я не знаю баз данных которые вам помогут.
Даже спустя столько времени актуально, спасибо! Хорошо объяснили, буду иметь ввиду и проверю все ваши советы
Спасибо!
Спасибо!
Спасибо !!! Поставил индексы и скрипт стал выполнятся не 750 сек, а 10 сек )
@unk unk ну мб там база на 60млн записей))) У меня на работе есть и больше
Здравствуйте! Не знал, что индексы так же помогают в сортировке данных.. Скажите вот у меня в таблице есть поле, которое принимает id родительского комментария и соответственно может повторятся, и тут возник вопрос стоит ли его индексировать? просто всегда думал, что индекс должен быть уникальным. Спасибо.
+Moon- -Ster Вы-же будете его использовать для JOIN-ов, так что скорее всего стоит.
+Moon- -Ster Уникальность не обязательна ))
Спасибо, за достоверную информацию, всегда бьете прямо в цель и суть вопроса!
Мужик !
Херню рассказал, равенство на хэш, больше/менш и т.д. на на битри ,есть ещё пару десятков алгоритмов, но они специфичны
Отличное видео! Спасибо
Спасибо дядька! Полезно.
Спасибо!
Володя спасибо, я все понял понял)
спасибо, давно искал такое простое объяснение