ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Более оптимизированный запрос.
25 сообщений из 25, страница 1 из 1
Более оптимизированный запрос.
    #38784808
zhurchick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zhurchick
Гость
Приветствую Вас Уважаемые форумчане.
Подскажите мне пожалуйста, что будет работать быстрее сравнение поля с пустой строкой или же сравнения поля с null, а именно:
`field1` = "" или же проверка на NULL - `field` IS NULL
На данный момент у меня поля field принимает по умолчанию пустую строку, но если NULL работает быстрее, то по умолчанию я его поставлю.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

таки да...а для таблицы айди 4 байта, и код - 4 однобайтных символа
введение поля нулл, добавляет один байт - это 1/8 = 12.5 %. настолько станут все дисковые операции больше изза тупо увеличения длины (размера) данных.
для операций с индексмо гдето столькоже. :) но для длины строки 50, 300 байт, это понты.
...
Рейтинг: 0 / 0
23.10.2014, 12:52:09
| Ответить | Цитировать | Написать  
Более оптимизированный запрос.
    #38785265
tanglir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tanglir
Участник
miksoftПодумалось... а если поле объявлено как NOT NULL, то MySQL догадается, что при проверке на IS NULL вообще ни в индекс, ни в таблицу лазить не надо?Да. idselect_typetabletypepossible_keyskeykey_lenrefrowsExtra1SIMPLENullNullNullNullNullNullNull Impossible WHERE
...
Рейтинг: 0 / 0
23.10.2014, 13:02:33
| Ответить | Цитировать | Написать  
Более оптимизированный запрос.
    #38785271
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Akina
Участник
miksoftПодумалось... а если поле объявлено как NOT NULL, то MySQL догадается, что при проверке на IS NULL вообще ни в индекс, ни в таблицу лазить не надо?
Для поля, объявленного как NOT NULL, проверка на IS NULL не является глупостью. Скажем, при левом связывании. Так что вряд ли в оптимизатор введена такая проверка.
...
Рейтинг: 0 / 0
23.10.2014, 13:05:24
| Ответить | Цитировать | Написать  
Более оптимизированный запрос.
    #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:10:50
| Ответить | Цитировать | Написать  
Более оптимизированный запрос.
    #38785302
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
AkinaДля поля, объявленного как NOT NULL, проверка на IS NULL не является глупостью. Скажем, при левом связывании.Да, мне надо было это учесть в постановке вопроса.
AkinaТак что вряд ли в оптимизатор введена такая проверка.Если оптимизатор сможет учесть факт внешнего связывания, то почему бы и нет?
...
Рейтинг: 0 / 0
23.10.2014, 13:22:22
| Ответить | Цитировать | Написать  
Более оптимизированный запрос.
    #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:10: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:25:38
| Ответить | Цитировать | Написать  
Более оптимизированный запрос.
    #38785487
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Akina
Участник
alex564657498765453нулл значение, его надо "преобразовать" к типу поляАсь?
Null интернационален, знаете ли... невозможно преобразовывать к какому-либо типу константу, у которой неизвестен тип - вернее, известно, что он не равен ни одному известному типу.
...
Рейтинг: 0 / 0
23.10.2014, 14:37:20
| Ответить | Цитировать | Написать  
Более оптимизированный запрос.
    #38785897
alex564657498765453
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alex564657498765453
Участник
Akinaalex564657498765453нулл значение, его надо "преобразовать" к типу поляАсь?
Null интернационален, знаете ли... невозможно преобразовывать к какому-либо типу константу, у которой неизвестен тип - вернее, известно, что он не равен ни одному известному типу.

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

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

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

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

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

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

и вот это приведение бабуйнии нулл к тому что будет реально выполняться и назвал преообразованием в кавычках. ибо смысл тотже что и любого другого преобразования типов...пулучить две цепочки байт, которые надо сравнить.
...
Рейтинг: 0 / 0
23.10.2014, 18:03:17
| Ответить | Цитировать | Написать  
25 сообщений из 25, страница 1 из 1
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Более оптимизированный запрос.
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=47&msg=38785302&tid=1834040]:
 0ms
get settings:
 8ms
get forum list:
 9ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 40ms
get topic data:
 6ms
get forum data:
 1ms
get page messages:
 34ms
get tp. blocked users:
 1ms
others: 232ms
total:  335ms
созд. / загр.: 335ms
x
x
Закрыть


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