Comments 39
Как-то все так сумбурно, я даже не уловил общую мысль :)
rtfm
Самые частые заблуждения при работе с базами данных. Даже без подробностей, чтобы в тонкости конкретной СУБД не вдаваться.
Ясно, перечитал и стало понятнее ) просто сначала как-то не вник
не осознал. 9а. Разве добавление индекса не ускоряет запрос?
Смотря какого индекса и смотря какой запрос. Пример из MySQL — сколько ты не добавляй индексы к строковому полю, но если поиск осуществляется REGEXP '...' или LIKE '%...%' (именно с процентом в начале needle) производительности это не прибавит.
Думаю что с REGEXP тоже можно использовать индекс в некоторых случаях (если вначале есть фиксированная часть) так же как с like '...%' :) Хотя данными относительного этого момента не располагаю.
Но смысл именно такой — если нет постоянной начальной части строки использование индекса невозможно (вернее все сводится к тому же пробегу по всем записям)
Но смысл именно такой — если нет постоянной начальной части строки использование индекса невозможно (вернее все сводится к тому же пробегу по всем записям)
Смотря какого индекса. Иногда лучше добавить поле к какому то индексу и в результате получить составной индекс. Второй момент добавление индекса может не повлиять на скорость выборки
а) если вы используете конструкции в запросе когда использование индекса не возможно (col_name like '%something' или date_add(col_name, 1 minute) = 'some_date' и т.п.)
б) данные на которые накладывается индекс имеют частые повторения. к примеру ваше поле хранит 100 уникальных значений и у вас 10 миллионов записей, такой индекс не прибавит вам скорости (конечно все зависит и от распределения значений (если значения равнораспределены то еще будет какой то смысл, иначе может и не быть), и прирост некоторый будет, но не значительный и не тот который мы ожидаем — а скорей всего не будет)
в) добавленный индекс может игнорироваться, так как может быть взят другой индекс (совсем не тот что вы ожидаете) — то есть добавляй индекс или не добавляй, он все равно использоваться не будет; выборка записей из одной таблицы осуществляется по одному индексу
К тому же добавление нового индекса не всегда хорошо. Новый индекс это дополнительные расходы на UPDATE, INSERT, DELETE и может быть неприемлемо когда у вас производятся частые обновления.
Так что добавление индекса это не спасение от всех бед — многое зависит от структуры таблицы, типов данных, структуры данные и самого запроса.
а) если вы используете конструкции в запросе когда использование индекса не возможно (col_name like '%something' или date_add(col_name, 1 minute) = 'some_date' и т.п.)
б) данные на которые накладывается индекс имеют частые повторения. к примеру ваше поле хранит 100 уникальных значений и у вас 10 миллионов записей, такой индекс не прибавит вам скорости (конечно все зависит и от распределения значений (если значения равнораспределены то еще будет какой то смысл, иначе может и не быть), и прирост некоторый будет, но не значительный и не тот который мы ожидаем — а скорей всего не будет)
в) добавленный индекс может игнорироваться, так как может быть взят другой индекс (совсем не тот что вы ожидаете) — то есть добавляй индекс или не добавляй, он все равно использоваться не будет; выборка записей из одной таблицы осуществляется по одному индексу
К тому же добавление нового индекса не всегда хорошо. Новый индекс это дополнительные расходы на UPDATE, INSERT, DELETE и может быть неприемлемо когда у вас производятся частые обновления.
Так что добавление индекса это не спасение от всех бед — многое зависит от структуры таблицы, типов данных, структуры данные и самого запроса.
Если правильно выбрать тип индекса — простой, составной, индекс по функции, да еще и не полагаться на оптимизатор, а указать в запросе какой именно индекс использовать, то — ускоряет.
Хотя в некоторых случаях — незначительно:)
Хотя в некоторых случаях — незначительно:)
Это далеко не панацея.
Если ускорять каждый запрос создавая именно под него индекс, то мы получим жуткий провал при INSERT или UPDATE по этой таблице.
Возможно стоит изменить запрос так чтобы он использовал какой-нибудь из уже существующих индексов, или создать один накрывающий индекс, который пускай не идеально, но подойдет под большинство запросов.
Если ускорять каждый запрос создавая именно под него индекс, то мы получим жуткий провал при INSERT или UPDATE по этой таблице.
Возможно стоит изменить запрос так чтобы он использовал какой-нибудь из уже существующих индексов, или создать один накрывающий индекс, который пускай не идеально, но подойдет под большинство запросов.
UFO just landed and posted this here
Не все СУБД умеют комбинировать индексы, к тому же часто скан одного из индексов с фильтром по второму условию кажется оптимизатору более предпочтительным
Вообще же мне кажется сомнительным мероприятием комбинирование индексов — можем получить неприятную картинку. По сути получается, что мы ищем по нескольким индексам, а потом делаем union? Кажется в таком случае много подводных камней и в редких случаях получится прирост. Можете направить где можно почитать по комбинирование индексов в рабочих СУБД?
Например в случае связывания двух и более таблиц по комбинации полей — составной индекс в каждой из связываемых таблиц по всем полям, участвующим в связке, существенно ускорит выполнение запроса (справедливо для MySQL 5.x). Другой вопрос что такое связывание не совсем нормально, но в некоторых случаях без него не обойтись.
Вы видимо не поняли. Тут имелось ввиду комбинирование индексов для одной таблицы. То есть имеем таблицу table у которой есть два индекса, так вот в нормальной ситуации большинство (хотя мне казалось все, но может меня поправят) СУБД будут использовать самый длинный индекс, но ОДИН. Автор предыдущего комментария заметил что некоторые СУБД могут принимать решение использовать оба индекса в такой ситуации (то есть что-то вроде искусственного составного индекса, который не был определен для таблицы). Насчет объединения нескольких таблиц — будут использоваться для каждой таблицы свой индекс, какой — уже определит оптимизатор или воспользуется хинтами в самом запросе. Но опять же для каждой таблицы будет использоваться только один индекс.
Извиняюсь за поздний комментарий. Комбинировать можно так называемые bitmap индексы, погуглите про них в oracle. Postgres хотя и не имеет настоящих bitmap-индексов, умеет делать bitmap-сканы — www.postgresql.org/docs/8.3/static/indexes-bitmap-scans.html
таки там будет лучше работать index(a, b)
Хоть бы кратко объяснили почему не так. А то ощущение незаконченности какое то :)
Давайте по порядку:
1. FAST = TRUE — на сколько я знаю, на самом деле был такой параметр, только он никак не был связан с разбором SQL
2. Явно бред, согласен. Слишком много факторов, которые на это влияют, начиная от хинтов, кончая физическим размещением датафайлов.
3. 50 на 50, надо смотреть в первую очередь план, если статистика у вас нормальная.
4. При хорошем знании оптимизатора и базы почему нет? Мне, например, для своей базы, достаточно посмотреть на не очень навороченный запрос, чтобы понять будет TAF или нет.
5. Смотря зачем вы используете временные таблицы и какой объем данных. Если у вас нужно просто переложить 1000000 записей, потом взять ID и в цикле для них что-то посчитать то зачем индекс??? У вас как минимум будут затраты на заполнение и сортировку индекса. Оно вам надо?
6. Внешний ключ ВСЕГДА требует unique index в родительской таблице. Или я не так вас понял?
7. Согласен, не всегда.
8. Ну и пример… Да… Если человек не видит различий между sql и pl/sql, то его надо тыкать в Concepts до полного усвоения.
9. Опять же тыкать в Perfomance Tuning Giude до полного переваривания.
Остальное — просто некомпетентность разработчика и непонимания сути индексирования, соединения и вообще принципов sql.
Короче надо такие таланты либо гнать, либо учить, это уже вам решать.
А вообще двоякое ощущение от топика, вроде бы есть что-то осмысленное, а с другой стороны столько спорных утверждений, что начинаешь сомневаться в компетентности автора, не в обиду будет сказано…
1. FAST = TRUE — на сколько я знаю, на самом деле был такой параметр, только он никак не был связан с разбором SQL
2. Явно бред, согласен. Слишком много факторов, которые на это влияют, начиная от хинтов, кончая физическим размещением датафайлов.
3. 50 на 50, надо смотреть в первую очередь план, если статистика у вас нормальная.
4. При хорошем знании оптимизатора и базы почему нет? Мне, например, для своей базы, достаточно посмотреть на не очень навороченный запрос, чтобы понять будет TAF или нет.
5. Смотря зачем вы используете временные таблицы и какой объем данных. Если у вас нужно просто переложить 1000000 записей, потом взять ID и в цикле для них что-то посчитать то зачем индекс??? У вас как минимум будут затраты на заполнение и сортировку индекса. Оно вам надо?
6. Внешний ключ ВСЕГДА требует unique index в родительской таблице. Или я не так вас понял?
7. Согласен, не всегда.
8. Ну и пример… Да… Если человек не видит различий между sql и pl/sql, то его надо тыкать в Concepts до полного усвоения.
9. Опять же тыкать в Perfomance Tuning Giude до полного переваривания.
Остальное — просто некомпетентность разработчика и непонимания сути индексирования, соединения и вообще принципов sql.
Короче надо такие таланты либо гнать, либо учить, это уже вам решать.
А вообще двоякое ощущение от топика, вроде бы есть что-то осмысленное, а с другой стороны столько спорных утверждений, что начинаешь сомневаться в компетентности автора, не в обиду будет сказано…
> 1. FAST = TRUE — на сколько я знаю, на самом деле был такой параметр, только он никак не был связан с > разбором SQL
Опа, это такой есть?
> 3. 50 на 50, надо смотреть в первую очередь план, если статистика у вас нормальная.
Статистика для большинства это вообще нечто из разряда фантастики :)
> 4. При хорошем знании оптимизатора и базы почему нет? Мне, например, для своей базы, достаточно > посмотреть на не очень навороченный запрос, чтобы понять будет TAF или нет.
Ага, при хорошем знании базы. Если базу хорошо знаешь таких вопросов даже не появляется.
Чаще бывает:
— Вот запрос в моем приложении тормозит. Как его переписать?
> 5.…
Я и не говорю что всегда надо. Но никто же никогда вообще не делает. Несмотря на то как временная таблица используется.
>6. Внешний ключ ВСЕГДА требует unique index в родительской таблице. Или я не так вас понял?
Я про индекс в дочерней вообще-то.
Опа, это такой есть?
> 3. 50 на 50, надо смотреть в первую очередь план, если статистика у вас нормальная.
Статистика для большинства это вообще нечто из разряда фантастики :)
> 4. При хорошем знании оптимизатора и базы почему нет? Мне, например, для своей базы, достаточно > посмотреть на не очень навороченный запрос, чтобы понять будет TAF или нет.
Ага, при хорошем знании базы. Если базу хорошо знаешь таких вопросов даже не появляется.
Чаще бывает:
— Вот запрос в моем приложении тормозит. Как его переписать?
> 5.…
Я и не говорю что всегда надо. Но никто же никогда вообще не делает. Несмотря на то как временная таблица используется.
>6. Внешний ключ ВСЕГДА требует unique index в родительской таблице. Или я не так вас понял?
Я про индекс в дочерней вообще-то.
1. Теперь нет. Последний раз он был в районе 6-7 версии, я этого уже не застал.
5 непонятно тогда, что вы написали в оригинале: «5. Во временных таблицах не надо делать ни Primary Key, ни индексов.» — если это миф, то почему сейчас вы говорите, что их вообще никто не использует? :)
6. Значит я неверно понял.
Ну а про все остальное — это просто недостаточная квалификация ваших сотрудников.
Уж поверьте мне, и «профи» пишут такие update-ы, что по 2 Тб (это не опечатка, именно террабайт) redo убивают. Так что и не стоит сильно расстраиваться. Просто надо либо увольнять, либо учить ;)
PS пример с select sum() очень уж жесткий…
5 непонятно тогда, что вы написали в оригинале: «5. Во временных таблицах не надо делать ни Primary Key, ни индексов.» — если это миф, то почему сейчас вы говорите, что их вообще никто не использует? :)
6. Значит я неверно понял.
Ну а про все остальное — это просто недостаточная квалификация ваших сотрудников.
Уж поверьте мне, и «профи» пишут такие update-ы, что по 2 Тб (это не опечатка, именно террабайт) redo убивают. Так что и не стоит сильно расстраиваться. Просто надо либо увольнять, либо учить ;)
PS пример с select sum() очень уж жесткий…
Забыл спросить, почему топик не в блоге SQL? Может перенесете???
На самом деле пропущен миф номер 0.
0. Существует в природе некий язык SQL. — и он базируется на реляционной алгебре.
Из этого заблуждения (вернее двух связанных заблуждений) рождаются все остальные. Многие ожидают что SQL ведёт себя как C++ или Java: ты пишешь нечто основываясь на формальной модели и можешь ожидать что реализация A будет вести себя примерно как реализация B. В принципе можно вообще отвлечься от реализации — и получить пусть не блестящий, но вполне хороший результат. В случае с Java ты можешь ожидать что, скажем, сериализация в Sun Java какие-то операции будут быстрее чем в GCJ, а какие-то медленнее, но это будут проценты, в худшем случае разы. В случае с C++ разница вообще редко 2x достигает. В случае с SQL'ем может быть так, что Oracle выполнит запрос за миллисекунду, а MySQL будет работать день. Или наоборот (что, впрочем, случается реже). Нужно примерно знать как это всё устроено внутри, какой путь проделывает ваш запрос и т.д. и т.п.
Короче говоря лучше воспринимать SQL как английский или русский: для обращения к Васе, Пете и Тане вроде как можно использовать один и тот же язык — но вот результат обращения гораздо больше зависит от знания вами личностей Васи, Пети и Тани, чем от знания вами языка. Если, конечно, вы просите их сделать что-то мало-мальски нетривиальное… А реляционная алгебра — это учебник грамматики языка: в реальном мире никто не говорит так, как там написано…
0. Существует в природе некий язык SQL. — и он базируется на реляционной алгебре.
Из этого заблуждения (вернее двух связанных заблуждений) рождаются все остальные. Многие ожидают что SQL ведёт себя как C++ или Java: ты пишешь нечто основываясь на формальной модели и можешь ожидать что реализация A будет вести себя примерно как реализация B. В принципе можно вообще отвлечься от реализации — и получить пусть не блестящий, но вполне хороший результат. В случае с Java ты можешь ожидать что, скажем, сериализация в Sun Java какие-то операции будут быстрее чем в GCJ, а какие-то медленнее, но это будут проценты, в худшем случае разы. В случае с C++ разница вообще редко 2x достигает. В случае с SQL'ем может быть так, что Oracle выполнит запрос за миллисекунду, а MySQL будет работать день. Или наоборот (что, впрочем, случается реже). Нужно примерно знать как это всё устроено внутри, какой путь проделывает ваш запрос и т.д. и т.п.
Короче говоря лучше воспринимать SQL как английский или русский: для обращения к Васе, Пете и Тане вроде как можно использовать один и тот же язык — но вот результат обращения гораздо больше зависит от знания вами личностей Васи, Пети и Тани, чем от знания вами языка. Если, конечно, вы просите их сделать что-то мало-мальски нетривиальное… А реляционная алгебра — это учебник грамматики языка: в реальном мире никто не говорит так, как там написано…
Это описаны пункты, когда говорящий ошибается?
Скомкано как-то, с опечатками, но суть понятна.
«Многие разработчики с немалым опытом разработки на любых императивных языках свято верят в то что SQL это тоже самое. Только синтаксис другой»
Хм… всегда так думал, идем в Вики и что мы видим:
ru.wikipedia.org/wiki/SQL
Независимость от конкретной СУБД:
Несмотря на наличие диалектов и различий в синтаксисе, в большинстве своём тексты SQL-запросов, содержащие DDL и DML, могут быть достаточно легко перенесены из одной СУБД в другую. Существуют системы, разработчики которых изначально закладывались на применение по меньшей мере нескольких СУБД (например: система электронного документооборота Documentum может работать как с Oracle Database, так и с Microsoft SQL Server и IBM DB2)
Наличие стандартов:
Наличие стандартов и набора тестов для выявления совместимости и соответствия конкретной реализации SQL общепринятому стандарту только способствует «стабилизации» языка.
Декларативность:
С помощью SQL программист описывает только то, какие данные нужно извлечь или модифицировать. То, каким образом это сделать решает СУБД непосредственно при обработке SQL запроса.
Хм… всегда так думал, идем в Вики и что мы видим:
ru.wikipedia.org/wiki/SQL
Независимость от конкретной СУБД:
Несмотря на наличие диалектов и различий в синтаксисе, в большинстве своём тексты SQL-запросов, содержащие DDL и DML, могут быть достаточно легко перенесены из одной СУБД в другую. Существуют системы, разработчики которых изначально закладывались на применение по меньшей мере нескольких СУБД (например: система электронного документооборота Documentum может работать как с Oracle Database, так и с Microsoft SQL Server и IBM DB2)
Наличие стандартов:
Наличие стандартов и набора тестов для выявления совместимости и соответствия конкретной реализации SQL общепринятому стандарту только способствует «стабилизации» языка.
Декларативность:
С помощью SQL программист описывает только то, какие данные нужно извлечь или модифицировать. То, каким образом это сделать решает СУБД непосредственно при обработке SQL запроса.
Это все хорошо в теории. На практике разработка под несколько разных СУБД означает разработку разных БД.
Почти весь код переписывать приходится. Отличия незначительные только на первый взгляд.
Почти весь код переписывать приходится. Отличия незначительные только на первый взгляд.
Нет, это понятно, просто различная реализация самих СУБД, и некоторые субд решают одни и теже вещи по разному, та даже взять разные типы таблиц в одном MySQL
Ну и зачем тогда постить комментарии о «Независимости от конкретной СУБД»?
Если сами знаете что это не так?
Если сами знаете что это не так?
Потому что это уже проблемы самих СУБД, и насколько они качественно подошли к выполнению инструкций…
И еще скажите что SELECТ * FROM table сложно перенести, или работу с JOIN, или еще какие-то, и вопрос не только в том что СБУД глупые
Вы всегда руководствуетесь инструкциями именно SQL при написании запросов? Всегда хочется воспользоваться преимуществами (надстройками) той или иной СУБД, вот и вы выбираете ту или иную СУБД с ее преимуществами…
Сам SQL остается один и тот же, изменяется только то как вы его используете…
И еще скажите что SELECТ * FROM table сложно перенести, или работу с JOIN, или еще какие-то, и вопрос не только в том что СБУД глупые
Вы всегда руководствуетесь инструкциями именно SQL при написании запросов? Всегда хочется воспользоваться преимуществами (надстройками) той или иной СУБД, вот и вы выбираете ту или иную СУБД с ее преимуществами…
Сам SQL остается один и тот же, изменяется только то как вы его используете…
Вы много видели проектов написанных именно на чистом ANSI SQL?
Всегда и везде используются расширения языка, просто потому что это удобно. Сильно ускоряется процесс разработки, упрощается код, улучшается производительность.
Неизвестно даже что проще. Сделать 2 версии заточенные под конкретные СУБД или одну но совместимую со всем.
А мифическая переносимость нужна очень редко. Какому нормальному человеку потребуется зачем-то менять один сервер на другой?
Всегда и везде используются расширения языка, просто потому что это удобно. Сильно ускоряется процесс разработки, упрощается код, улучшается производительность.
Неизвестно даже что проще. Сделать 2 версии заточенные под конкретные СУБД или одну но совместимую со всем.
А мифическая переносимость нужна очень редко. Какому нормальному человеку потребуется зачем-то менять один сервер на другой?
Речь шла о независимости приложения от СУБД, и это вполне уместно.
Приложение (при соответствующей архитектуре) вполне комфортно переживет смену источника данных — за него отдувается драйвер СУБД на клиенте и хранимые процедуры на сервере.
Приложение (при соответствующей архитектуре) вполне комфортно переживет смену источника данных — за него отдувается драйвер СУБД на клиенте и хранимые процедуры на сервере.
Sign up to leave a comment.
Мифы SQL