Comments 17
Спасибо. Действительно весьма полезная статья
довлольно любопытно и познавательно. Еще бы планы запросов понавставлять для наглядности того, что происходит.
Хотел бы возразить по поводу
>> Скорость соединения таблиц сильно зависит от типов и количества полей по которым мы их соединяем
У вас в строковое поле (если я правильно понял) заносится номер строки, т.е. макс кол-во символов для вашего примера = 5 («9999»).
А если рассматривать бОльшие строки.
Мне пришлось столкнуться с ситуацией, когда IP адреса в системе учета трафика хранились в виде строк, а это 15 символов (максимум). Для сравнения я добавил поле int_IP — беззнаковое целое (занимает в mysql 4 байта). Скорость работы скрипта увеличилась в разы (точно не помню, где то в 3-4 раза) при размере таблицы в 10 млн строк.
ИМХО скорость соединения зависит от типов полей.
>> Скорость соединения таблиц сильно зависит от типов и количества полей по которым мы их соединяем
У вас в строковое поле (если я правильно понял) заносится номер строки, т.е. макс кол-во символов для вашего примера = 5 («9999»).
А если рассматривать бОльшие строки.
Мне пришлось столкнуться с ситуацией, когда IP адреса в системе учета трафика хранились в виде строк, а это 15 символов (максимум). Для сравнения я добавил поле int_IP — беззнаковое целое (занимает в mysql 4 байта). Скорость работы скрипта увеличилась в разы (точно не помню, где то в 3-4 раза) при размере таблицы в 10 млн строк.
ИМХО скорость соединения зависит от типов полей.
для оракла это не столь принципиально. Близкое по теме обсуждение было совсем недавно.
Я не силен в оракл, тем более в его типах данных. В ссылке, приведенной вами, ведется обсуждение про строки, размерность которых сравнима между собой. Я же привел пример, про то, что есть разница сравниваем ли мы целочисленные поля, которые занимают 4 байта или же строки которые занимают 15 байт. имхо, очевидно, что сравнить меньшее количество байт быстрее.
Для текстового поля я использовал varchar2(1024)
Это строка длиной 1024 символа.
Если есть индекс по полю, то что именно лежит в этом поле абсолютно не важно.
Это строка длиной 1024 символа.
Если есть индекс по полю, то что именно лежит в этом поле абсолютно не важно.
Насколько мне известно отличие char от varchar в том, что varchar — переменной длины, т.е если varchar(1024) — это строка длиной ДО 1024 символов. Т.е. если в эту строку записать 10 символов, то занимаемый объем будет 12 байт (первые 2 байта — длина строки, 10 — сама строка).
>> Если есть индекс по полю, то что именно лежит в этом поле абсолютно не важно.
Согласен.
P.S. В моем случае индекса не было.
>> Если есть индекс по полю, то что именно лежит в этом поле абсолютно не важно.
Согласен.
P.S. В моем случае индекса не было.
Ну так и написано «сильно зависит»
«То будет гораздо эффективнее создать составной индекс (id, code) и автоматически созданный (id) будет только мешать.» не будет, статистика наше все :)
«Абсолютная идентичность следующих вариантов кода» — проще было бы привести пример использования pl/sql функции в sql запросе, было у Кайта, не могу сейчас найти. Суть такова — все, что можно сделать средствами sql надо делать средствами sql. Точка. Для большого кол-ва данных вызов pl/sql функций в запросе просто не допустим.
Еще не понятно, почему у вас count(*) по индексу медленнее отработал… Вам бы табличку не из одного поля бы сделать, глядишь и ситуация изменилась бы. Вообще у вас идея правильная, но пример не очень удачный имхо. А объяснить это можно просто почитаю, что есть индекс и как он работает. Вообще то десятка весьма хорошо понимает, когда использовать TAF, а когда Index Scan.
И еще немного косметики:
1) зачем в DDL таблиц описание хранения? Имхо смело удалить надо.
2) Внешний ключ = Индекс по полю в дочерней таблице — после этого ничитаемо — уехали строчки за баннер (FF 2)
3) Тестовые таблички, имхо, проще создавать Create table as select
«Абсолютная идентичность следующих вариантов кода» — проще было бы привести пример использования pl/sql функции в sql запросе, было у Кайта, не могу сейчас найти. Суть такова — все, что можно сделать средствами sql надо делать средствами sql. Точка. Для большого кол-ва данных вызов pl/sql функций в запросе просто не допустим.
Еще не понятно, почему у вас count(*) по индексу медленнее отработал… Вам бы табличку не из одного поля бы сделать, глядишь и ситуация изменилась бы. Вообще у вас идея правильная, но пример не очень удачный имхо. А объяснить это можно просто почитаю, что есть индекс и как он работает. Вообще то десятка весьма хорошо понимает, когда использовать TAF, а когда Index Scan.
И еще немного косметики:
1) зачем в DDL таблиц описание хранения? Имхо смело удалить надо.
2) Внешний ключ = Индекс по полю в дочерней таблице — после этого ничитаемо — уехали строчки за баннер (FF 2)
3) Тестовые таблички, имхо, проще создавать Create table as select
COUNT(*) именно поэтому медленнее и отработал. Согласен там наложилось то что таблица из одного поля. Но это не так принципиально, основную идею видно. Индекс бывает медленнее, а в каких именно случаях разбирать на целую статью хватит.
Ага, 10 хорошо знает где какой метод доступа использовать. Пришлось хинты писать чтобы Index Scan получить.
1. А как иначе? Код чтобы легко повторить у себя можно было. Просто создаем пустую схему, копируем, выполняем и изучаем почему так получилось.
2. AdBlock и никаких баннеров на хабре я не вижу
3. Кто как привык. Мне из дуала удобнее.
Ага, 10 хорошо знает где какой метод доступа использовать. Пришлось хинты писать чтобы Index Scan получить.
1. А как иначе? Код чтобы легко повторить у себя можно было. Просто создаем пустую схему, копируем, выполняем и изучаем почему так получилось.
2. AdBlock и никаких баннеров на хабре я не вижу
3. Кто как привык. Мне из дуала удобнее.
> «То будет гораздо эффективнее создать составной индекс (id, code) и автоматически > созданный (id) будет только мешать.» не будет, статистика наше все :)
Будет мешать при вставках в таблицу. Да и нефига лишние индексы держать в схеме, отвлекают.
Будет мешать при вставках в таблицу. Да и нефига лишние индексы держать в схеме, отвлекают.
Имхо, половина мифов высосана из пальца. Любой вменяемый девелопер сначала разбирается в сути происходящего, а потом уже использует полученные знания на практике. Если конечно исключения, когда «надо сделать шоб работало и прям сейчас», но даже в таком случае возникает необходимость постфактум восполнить пробелы «по теме».
Спасибо, интересно :)
Надеюсь, будет продолжение!
Надеюсь, будет продолжение!
«зультаты» — опечатка в начале статьи :)
Sign up to leave a comment.
Мифы SQL. Продолжение.