Многие слышали про индексы в базах данных, но обсуждение по поводу когда стоит создавать эти индексы встречается в просторах интернета не так уж и часто. Этот урок как раз об этом.
Мужииииииик, ты вообще крут, большой большой большой респект тебе, где ты раньше был, я ещё раз и гораздо лучше все это понял ))))) Ждём твоих видео ))))))
Смотрел эти Мини-лекции ещё когда учился в школе, вот уже два года как выпустился из университета. В универе благодаря Владимиру экономил своё время перед экзаменами. Теперь работаю и иногда освежаю информацию в памяти. Спасибо вам!
супер видео! благодарю, кратко понятно. вопросы задают на собеседование. Я так понял, надо все запросы из программы собрать, после проанализировать какие поля в where используются и создать по ним индекс.
Спасибо! Хорошо объяснили. Будут ли видео о проектировании баз данных? Какие-то рекомендации на эту тему? Нормализации таблиц, денормализации, ведь это тоже с производительностью тесно свзяано, например много JOIN'ов не есть хорошо и.т.д.
При update/insert ты едва ли что-то теряешь при использовании индекса. Потеря константна. А вот при select ты очень много экономишь при использовании индекса. Экономия зависит от величины базы. И ради солнца, ставьте индексы на внешний ключ, всегда) История из жизни: выполнялась по cron'у раз в минуту одна процедура. Ну секунд 20-30 занимала, вроде норм. Шли месяца... Данных становилось все больше, и больше. Стало так много, что эта процедура стала занимать больше минуты. В итоге процессы не успевали закончитьься, как появлялись такие же новые. Больше процессов, меньше ресурсов - еще медленнее процедуры - еще больше процедур. Ну вы наверное уже поняли к чему я клоню. Сервер упал))) Сервер пролежал 7 часов! Пока все опомнились, пока сообщили нужным людям, а те другим людям, а те программистам, пока программист подключился, перезагрузил сервер, все поднял, обнаружил проблему, поправил... Так что не ленитесь ставить индексы!) Для сравнения, после добавления одного единственного индекса процедура стала занимать ~8 секунд! А там записей было не так много, немногим больше миллиона.
Автор, немного серьезнее отнестись к тому, что говорите. Вы делаете акцент на том, что Having выполняется после в конце, но это не аргумент, т.к. Order by выполняется вообще последним, после Select, перед которым выполняется Having. И то что "для select нужно сдавать индексы, а для update нет" - это конечно тоже странное утверждение, учитывая что update - в используемом контексте это и select также, со своими возможными предикатами, для которых тоже используется индекс.
Спасибо очень наглядно, подскажи пожалуйста если делать инсерт новых строк то индекс на них индекс автоматом встанет? И ещё вопрос апдейт быстрее чем перезапись всей таблицы (более 10млн строк) ?
Добрый день! Команда CREATE MATERIALIZED VIEW AS SELECT вставляя данные в мат. витрину под капотом использует INSERT.? По сути она вставляет данные., значит это INSERT?
Как общая теория пойдет, вы знаете, что бывают различные алгоритмы индексов, каждый под свою задачу. Так что важно было упомянуть с какими данными приходится работать
Объясните пожалуйста, для чего нужны связи, отношения. Не совсем пойму логическое для чено они нужны. Весь интернет заполнен этими связями а вот для чего они нужны не совсем понятно, никто не объясняет. Объясните пожалуйста
Здравствуйте! Не знал, что индексы так же помогают в сортировке данных.. Скажите вот у меня в таблице есть поле, которое принимает id родительского комментария и соответственно может повторятся, и тут возник вопрос стоит ли его индексировать? просто всегда думал, что индекс должен быть уникальным. Спасибо.
+Абакумов Андрей Здесь уже, на сколько я знаю, зависит от конкретной базы данных. Многие и такое могут оптимизировать. Например они могут использовать бинарные (или другие) деревья для ускорения поиска... и тд. Но вот например если вы уже используете регулярное выражение, тут я не знаю баз данных которые вам помогут.
Здравствуйте!Вопрос такой , у меня поле при инсерте записи изначально null но потом апдейтится только один раз. Данное поле участвует в join.Стоит его индексировать ?
теория- это хорошо. хорошо объяснённая теория - ещё лучше. но без практики некоторый туман в понимании остаётся. прям, не хватает практического обучения SQL с нуля.
Не очевидно, почему вдруг операторы сравнения исключают индексирование. 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 таблицы с множеством атрибутов и данных с установленным индексом на каждый. при каждом изменении запроса и требований изменяется структура таблицы если это нужно,
Владимир, спасибо вам огромное, за то, что дарите свет знаний нам, тёмным. Мне 40, переквалифицировался в программисты и учусь по вашим видео!
Мужииииииик, ты вообще крут, большой большой большой респект тебе, где ты раньше был, я ещё раз и гораздо лучше все это понял ))))) Ждём твоих видео ))))))
Смотрел эти Мини-лекции ещё когда учился в школе, вот уже два года как выпустился из университета. В универе благодаря Владимиру экономил своё время перед экзаменами. Теперь работаю и иногда освежаю информацию в памяти.
Спасибо вам!
Даже спустя столько времени актуально, спасибо! Хорошо объяснили, буду иметь ввиду и проверю все ваши советы
Пожалуй лучшее видео о том, как и когда лучше использовать индексы. Благодарю!
Спасибо Владимир!
Спасибо, уложил мне и другим все в голове, от вас бы еще сравнение разных баз данных для разных задач )
Спасибо, за достоверную информацию, всегда бьете прямо в цель и суть вопроса!
Расскажи пожалуйста про составные индексы и про очерёдность столбцов, хотелось бы ещё видеть как писать код
супер видео! благодарю, кратко понятно. вопросы задают на собеседование. Я так понял, надо все запросы из программы собрать, после проанализировать какие поля в where используются и создать по ним индекс.
Большое спасибо за подробное разъяснение, а то я сам чуть все индексами не сделал ;)
Это супер! Очень помогли при архитектуре БД и составлении схем в ORM, спасибо!
Спасибо! Хорошо объяснили. Будут ли видео о проектировании баз данных? Какие-то рекомендации на эту тему? Нормализации таблиц, денормализации, ведь это тоже с производительностью тесно свзяано, например много JOIN'ов не есть хорошо и.т.д.
При update/insert ты едва ли что-то теряешь при использовании индекса. Потеря константна.
А вот при select ты очень много экономишь при использовании индекса. Экономия зависит от величины базы.
И ради солнца, ставьте индексы на внешний ключ, всегда)
История из жизни: выполнялась по cron'у раз в минуту одна процедура. Ну секунд 20-30 занимала, вроде норм. Шли месяца... Данных становилось все больше, и больше. Стало так много, что эта процедура стала занимать больше минуты. В итоге процессы не успевали закончитьься, как появлялись такие же новые. Больше процессов, меньше ресурсов - еще медленнее процедуры - еще больше процедур. Ну вы наверное уже поняли к чему я клоню. Сервер упал)))
Сервер пролежал 7 часов! Пока все опомнились, пока сообщили нужным людям, а те другим людям, а те программистам, пока программист подключился, перезагрузил сервер, все поднял, обнаружил проблему, поправил... Так что не ленитесь ставить индексы!)
Для сравнения, после добавления одного единственного индекса процедура стала занимать ~8 секунд! А там записей было не так много, немногим больше миллиона.
Jerry Green так ваша история не про индексы, а про то что надо использовать flock, если команду стоит запускать в одном экземпляре
Супер!
Чуть подробнее интересно было бы услышать про WHERE с операторами сравнения "больше" и "меньше".
Ничего нового не узнал, имею богатый опыт, но хочу отметить очень качественную, доходчивую и лёгкую к восприятию подачу материала.
Супер! Всё очень доходчиво, большое Вам спасибо!
Молодец! Спасибо, за материал.
Отличное видео! Спасибо
Володя спасибо! Хорошо рассказываешь. Расскажи какие типы индексов использовать в каких случаях.
Коротко и по делу. Очень годно.
огромная спасибо! отличное объяснение! долго в голове не укладывалось
Что поменялось спустя 5 лет? Советы индексирования остались те же? Или есть какие-то изменения?
Автор, немного серьезнее отнестись к тому, что говорите. Вы делаете акцент на том, что Having выполняется после в конце, но это не аргумент, т.к. Order by выполняется вообще последним, после Select, перед которым выполняется Having.
И то что "для select нужно сдавать индексы, а для update нет" - это конечно тоже странное утверждение, учитывая что update - в используемом контексте это и select также, со своими возможными предикатами, для которых тоже используется индекс.
Спасибо очень наглядно, подскажи пожалуйста если делать инсерт новых строк то индекс на них индекс автоматом встанет? И ещё вопрос апдейт быстрее чем перезапись всей таблицы (более 10млн строк) ?
Спасибо! Вы очень хорошо объясняете!
Спасибо дядька! Полезно.
спасибо за полезную информацию
Отлично все объяснил! Спасибо)
Вопрос: а если колонка часто используется в секции WHERE, но при этом так же часто подвергается UPDATE'у?
Подскаэите пжлста есть ли смысл создавать индекс для таблицы где всего две колонки форен кей
Отлично спасибо ! Частные уроки по скайпу проводите ?
Добрый день!
Команда CREATE MATERIALIZED VIEW AS SELECT вставляя данные в мат. витрину под капотом использует INSERT.? По сути она вставляет данные., значит это INSERT?
Спасибо за лекцию. Очень помогли
Отличное видео! Большое спасибо
Как общая теория пойдет, вы знаете, что бывают различные алгоритмы индексов, каждый под свою задачу. Так что важно было упомянуть с какими данными приходится работать
Объясните пожалуйста, для чего нужны связи, отношения. Не совсем пойму логическое для чено они нужны. Весь интернет заполнен этими связями а вот для чего они нужны не совсем понятно, никто не объясняет. Объясните пожалуйста
Зачем вы учите тому, в чём не разбираетесь? К примеру в постгрес, запросы where > < >=
урок пушка, спасибо!
а если в ON есть операция >?
почему сравнение больше/меньше менее эффективно чем равенство？
Володя спасибо, я все понял понял)
Мне пока кажется, что для Join on в первую очередь нужно делать индекс. приоритетнее чем where.
Лучший!
спасибо, давно искал такое простое объяснение
а если я ищу не через оператор = ,а через оператор IN и поиск у меня происходит по нескольким полям IN(поле1, поле2)?
А аналогом чего в sql является in? Ответив на этот вопрос, получите ответ на изначальный
Спасибо !!! Поставил индексы и скрипт стал выполнятся не 750 сек, а 10 сек )
@unk unk ну мб там база на 60млн записей))) У меня на работе есть и больше
Спасибо, очень информативно
Здравствуйте! Не знал, что индексы так же помогают в сортировке данных.. Скажите вот у меня в таблице есть поле, которое принимает id родительского комментария и соответственно может повторятся, и тут возник вопрос стоит ли его индексировать? просто всегда думал, что индекс должен быть уникальным. Спасибо.
+Moon- -Ster Вы-же будете его использовать для JOIN-ов, так что скорее всего стоит.
+Moon- -Ster Уникальность не обязательна ))
если update с блоком where, то индекс будет задействован и тоже поможет)
ээээ... это сколько кже лет посгри индексирует и лайк, и сравнения в зависимости от индекса?? (b tree)
Комментарий для продвижения видео
Гений!
Спасибо!
Вроды бы для запросов с like вида "%something", "something%" и "%something%" index будет полезен
+Абакумов Андрей Здесь уже, на сколько я знаю, зависит от конкретной базы данных. Многие и такое могут оптимизировать. Например они могут использовать бинарные (или другие) деревья для ускорения поиска... и тд. Но вот например если вы уже используете регулярное выражение, тут я не знаю баз данных которые вам помогут.
Володя я тебя люблю
Мужик !
Здравствуйте!Вопрос такой , у меня поле при инсерте записи изначально null но потом апдейтится только один раз. Данное поле участвует в join.Стоит его индексировать ?
Определенно да, если после апдейта не будет новых, а только участие этого поля в запросах на выборку данных (в т.ч. при джойнах).
Спасибо.
👍
Добрый день , можно узнать почему на этом видео стд лицензия ?
+Иван Иванович Исправил. Если заметите такое ещё, дайте знать.
👍🏻👍🏻👍🏻
теория- это хорошо. хорошо объяснённая теория - ещё лучше. но без практики некоторый туман в понимании остаётся. прям, не хватает практического обучения SQL с нуля.
Не очевидно, почему вдруг операторы сравнения исключают индексирование. B-tree целиком построено на сравнениях. Ощущение, что лектор не очень хорошо понимает, как устроены индексы.
Не очевидно, потому что не исключают.
@@VladimirMozhenkov в ролике сказано, что идексы похдходят только для случаев, где у нас сравнение на равенство, но не на больше / меньше
Почему для like не нужен индекс? Наверно речь идёт о неопределенном начале строки? Like % ... %
Для like ... % индекс ускорит работу
Топ
Ролик конечно же полезный, но в нём не рассматриваются ситуации использования 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 будет полезен
Однозначно, коллега! )
Спасибо!!!
Спасибо!
Спасибо!
Спасибо!