Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Более оптимизированный запрос. / 25 сообщений из 25, страница 1 из 1
23.10.2014, 01:57:41
    #38784808
zhurchick
zhurchick
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Более оптимизированный запрос.
Приветствую Вас Уважаемые форумчане.
Подскажите мне пожалуйста, что будет работать быстрее сравнение поля с пустой строкой или же сравнения поля с null, а именно:
`field1` = "" или же проверка на NULL - `field` IS NULL
На данный момент у меня поля field принимает по умолчанию пустую строку, но если NULL работает быстрее, то по умолчанию я его поставлю.

Из Вашего опыта! Какой путь выбрать? Что работает быстрее? И если можно почему?
Заранее большое спасибо.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.10.2014, 08:58:01
    #38784887
Akina
Akina
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Более оптимизированный запрос.
Проверка на Null быстрее.

Во-первых, она независима от типа поля. Гарантированно отсутствуют неявные преобразования типов.
Во-вторых, это сравнение со специальным значением, имеющим чисельный тип, т.е. не требуется организация итерационного посимвольного цикла сравнения.
В третьих, при извлечении из индекса Null гарантированно там весь, в то время как от строки может быть только хедер.
Есть ещё несколько соображений.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.10.2014, 09:53:09
    #38784944
miksoft
miksoft
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Более оптимизированный запрос.
Akina,

А я вот запамятовал. MySQL хранит NULL-ы в индексах? Некоторые другие СУБД не хранят.

Если хранит, то сравнение с NULL, наверное, быстрее. Но, думаю, на ничтожную величину, в пределах погрешности измерения.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.10.2014, 10:27:23
    #38784999
zhurchick
zhurchick
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Более оптимизированный запрос.
Akina,
Спасибо за столь развернутый ответ.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.10.2014, 10:29:30
    #38785002
zhurchick
zhurchick
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Более оптимизированный запрос.
miksoft,
СУБД MySQL!

Прямо-таки незначительная разница?
А по фактам которые предоставил Akina сложно сказать это.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.10.2014, 11:02:48
    #38785047
miksoft
miksoft
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Более оптимизированный запрос.
zhurchickПрямо-таки незначительная разница?
А по фактам которые предоставил Akina сложно сказать это.Ну давайте по фактам...
1) Пустая строка будет иметь тип строки. Если поле имеет строковый тип (а иначе сам вопрос теряет смысл), то преобразования типов не требуется.
2) Посимвольное сравнение выполняется циклом по длине кратчайшей строки. Поскольку длина одной из строк равна нулю, то будет выполнено ноль итераций сравнения. Чуть-чуть времени потребует на проверку поля на NOT NULL и вычисление длины кратчайшей строки (взять минимум из двух чисел).
3) Хедер пустой строки гарантированно уместится в индекс, какой бы префикс ни был у него указан. И он потребует всего лишь 1-4 байта в индексе.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.10.2014, 11:06:51
    #38785057
zhurchick
zhurchick
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Более оптимизированный запрос.
miksoft,
В принципе, Вы правы.
Лично Вы что бы посоветовали? Использовать поле типа NULL или оставить строку?
Только вот я не совсем понял, что такое хедер? Типа заголовок какой-то?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.10.2014, 11:13:30
    #38785072
Akina
Akina
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Более оптимизированный запрос.
zhurchick Использовать поле типа NULL или оставить строку?
Я бы, например, посоветовал придерживаться сути модели. Пустая строка - это всё-таки значение. Null - это отсутствие значения, в том числе и отсутствие пустой строки.
Это разные вещи. И что когда использовать, должно определяться физикой процесса, а не мнимым выигрышем в скорости. Например, по пустой строке связывать можно, а по NULL - вот не вдруг...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.10.2014, 11:27:08
    #38785096
zhurchick
zhurchick
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Более оптимизированный запрос.
Akina,
Тогда для моей задачи больше подходит NULL)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.10.2014, 11:28:41
    #38785098
zhurchick
zhurchick
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Более оптимизированный запрос.
Парни, а тут (на этом сайте) имеется ли вообще понятие КАРМА? Как я могу Вас отблагодарить?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.10.2014, 11:34:21
    #38785107
tanglir
tanglir
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Более оптимизированный запрос.
zhurchickа тут (на этом сайте) имеется ли вообще понятие КАРМА? 15530455
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.10.2014, 12:44:32
    #38785236
alex564657498765453
alex564657498765453
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Более оптимизированный запрос.
я думаю что в целом нулл будет медленее.

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

само поле, которое может быть нулл - потребляет лишний байт, поэтому значение индекса

будет лишний байт+остальные байты, и для такого поля любая процедура сравнения, включает сначала проверку нулл байта

тоесть при поле = 'vasya' мы первым шагом идя по дереву индекса проверим нулл байт, нам нужны те что нулл байт равен нулю - тоесть не нулл значение.

по сути работа такого индекса имеет предваритльный шаг NOT NULL
а потом как обычный.

это поиск любого значения отличного от нулл.

теперь нулл и пустая строка.

для индекса (допустим длина индекса один символ-один байт)

строка нулевой длины, это тоже что для индекса на однобайтовое числовое поле значение 0

ну то есть для байтового значения возможные значения ключа 0..255
для текстового по одному символу - теже самые.

если не один а несколько байт...да по бую..всё тоже самое.

индексное значение строки нулевой длины - 0 (или ктото думает что другое? :))

поэтому вопрос равнозначен

а будет ли быстрее если я буду вместо чисел 0 хранить нулл. ?

ЗЫ
не спорю, на сайте мускла это не написано, но вроде как я добросовесно учил оптимизации поиска, итаки знаю...при построении индекса на цепочки байт для цепучки нулевой длины берёться значение 0.

индекс может быть либо длинна_цепочки+сама цепочка
либо просто сама_цепочка+0байт

при любом раскладе, кодирование строки нулевой длины - это 0х00
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.10.2014, 12:47:10
    #38785242
MasterZiv
MasterZiv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Более оптимизированный запрос.
Ребята, по сравнению с временем чтения страницы -- это мизер.
Очень мало. Так что что в лоб, что по лбу.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.10.2014, 12:51:03
    #38785250
miksoft
miksoft
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Более оптимизированный запрос.
Подумалось... а если поле объявлено как NOT NULL, то MySQL догадается, что при проверке на IS NULL вообще ни в индекс, ни в таблицу лазить не надо?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.10.2014, 12:52:09
    #38785252
alex564657498765453
alex564657498765453
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Более оптимизированный запрос.
MasterZivРебята, по сравнению с временем чтения страницы -- это мизер.
Очень мало. Так что что в лоб, что по лбу.

таки да...а для таблицы айди 4 байта, и код - 4 однобайтных символа
введение поля нулл, добавляет один байт - это 1/8 = 12.5 %. настолько станут все дисковые операции больше изза тупо увеличения длины (размера) данных.
для операций с индексмо гдето столькоже. :) но для длины строки 50, 300 байт, это понты.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.10.2014, 13:02:33
    #38785265
tanglir
tanglir
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Более оптимизированный запрос.
miksoftПодумалось... а если поле объявлено как NOT NULL, то MySQL догадается, что при проверке на IS NULL вообще ни в индекс, ни в таблицу лазить не надо?Да. idselect_typetabletypepossible_keyskeykey_lenrefrowsExtra1SIMPLENullNullNullNullNullNullNull Impossible WHERE
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.10.2014, 13:05:24
    #38785271
Akina
Akina
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Более оптимизированный запрос.
miksoftПодумалось... а если поле объявлено как NOT NULL, то MySQL догадается, что при проверке на IS NULL вообще ни в индекс, ни в таблицу лазить не надо?
Для поля, объявленного как NOT NULL, проверка на IS NULL не является глупостью. Скажем, при левом связывании. Так что вряд ли в оптимизатор введена такая проверка.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.10.2014, 13:10:50
    #38785283
Akina
Akina
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Более оптимизированный запрос.
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
mysql> create table test (id int auto_increment primary key, val int not null);
Query OK, 0 rows affected (0.14 sec)

mysql> explain select * from test where val is null;
+----+-------------+-------+------+---------------+------+---------+------+------+------------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra            |
+----+-------------+-------+------+---------------+------+---------+------+------+------------------+
|  1 | SIMPLE      | NULL  | NULL | NULL          | NULL | NULL    | NULL | NULL | Impossible WHERE |
+----+-------------+-------+------+---------------+------+---------+------+------+------------------+
1 row in set (0.00 sec)

mysql> explain select * from test where val < 100 or val is null;
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra       |
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
|  1 | SIMPLE      | test  | ALL  | NULL          | NULL | NULL    | NULL |    3 | Using where |
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
1 row in set (0.02 sec)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.10.2014, 13:22:22
    #38785302
miksoft
miksoft
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Более оптимизированный запрос.
AkinaДля поля, объявленного как NOT NULL, проверка на IS NULL не является глупостью. Скажем, при левом связывании.Да, мне надо было это учесть в постановке вопроса.
AkinaТак что вряд ли в оптимизатор введена такая проверка.Если оптимизатор сможет учесть факт внешнего связывания, то почему бы и нет?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.10.2014, 14:10:38
    #38785406
Akina
Akina
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Более оптимизированный запрос.
Да я к тому, что от того учёта ни холодно ни жарко. Constant evaluation всё равно производится самым первым делом, и я думаю, что заведомо не влияющие константы отсеиваются достаточно грамотно - например, в моей цитате в условии отбора where val < 100 or val is null сразу выполняется приведение его к where val < 100 or false и далее к where val < 100 . Плюс несравнимость скорости дисковых операций с этими проверочными телодвижениями.

Ну а чистое where val is null на not-null поле скорее свидетельствует о необходимости для программиста на время сменить род занятий, чем о чём-либо ещё.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.10.2014, 14:25:38
    #38785442
alex564657498765453
alex564657498765453
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Более оптимизированный запрос.
на тему нот нулл для поля которое не может быть нулл
...
a integer not null default 0,
...
where
a is null

эквивалент по логике
where 1 =2

но более медленное первое.

мускл же при распознавании запроса следующим шагом делает все константные вычисления и
где надо преобразования типов.

нулл значение, его надо "преобразовать" к типу поля
тип поля в нашем случае интеджер, а не нул_байт_флаг+интеджер, вот и получаеться сразу фолс...вычисляеться как константа

в эксплейне impossible where - означает что вся секция веар вычислена до запроса - там константное выражение, и оно всегда ложно.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.10.2014, 14:37:20
    #38785487
Akina
Akina
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Более оптимизированный запрос.
alex564657498765453нулл значение, его надо "преобразовать" к типу поляАсь?
Null интернационален, знаете ли... невозможно преобразовывать к какому-либо типу константу, у которой неизвестен тип - вернее, известно, что он не равен ни одному известному типу.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.10.2014, 17:56:54
    #38785897
alex564657498765453
alex564657498765453
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Более оптимизированный запрос.
Akinaalex564657498765453нулл значение, его надо "преобразовать" к типу поляАсь?
Null интернационален, знаете ли... невозможно преобразовывать к какому-либо типу константу, у которой неизвестен тип - вернее, известно, что он не равен ни одному известному типу.

для того и написал слово в кавычках!!!
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.10.2014, 17:58:03
    #38785900
tanglir
tanglir
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Более оптимизированный запрос.
alex564657498765453,

для чего? нулл вообще преобразовывать не надо.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.10.2014, 18:03:17
    #38785906
alex564657498765453
alex564657498765453
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Более оптимизированный запрос.
alex564657498765453Akinaпропущено...
Ась?
Null интернационален, знаете ли... невозможно преобразовывать к какому-либо типу константу, у которой неизвестен тип - вернее, известно, что он не равен ни одному известному типу.

для того и написал слово в кавычках!!!

в данном случае "преобразования" свёдёться к
сначала проверке возможности подобной операции, она не возможно, ибо у поля нету нужного байта где можно посмотреть - нул или не нул значение - сразу фолс.
если бы было, но такойто там внутрений код действия означающий сравнить два байта
байт "нулл значения" ..наверно просто единица 0х01, с нуллфлагом поля...тот самый добавочный байт. вот они должны быть равны.

ЗЫ
я всмысле микропроцесор не знает такого типа как нулл, это интерпритация...точно так же как знак целого числа, которого также по сути не существует для микропроцессора.

чтобы там мы ни писали словами, микропроцессору надо будет сравнивать число с числом

и вот это приведение бабуйнии нулл к тому что будет реально выполняться и назвал преообразованием в кавычках. ибо смысл тотже что и любого другого преобразования типов...пулучить две цепочки байт, которые надо сравнить.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Более оптимизированный запрос. / 25 сообщений из 25, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 298ms
Закрыть
start [/forum/topic.php?fid=47&tablet=1&tid=1834040]:
 0ms
get settings:
 5ms
get forum list:
 9ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 49ms
get topic data:
 5ms
get forum data:
 1ms
get page messages:
 30ms
get tp. blocked users:
 1ms
others: 194ms
total:  298ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]