Комментарии 15
Подписался бы под каждым словом. Особенно «Использование * в запросе». Поди разбери в коде, потом какие колонки вообще есть, а так видно.
Ну звездочки это то, с чего обычно начинается изучение SQL, в большинстве учебников, примеров и т.п. самый базовый запрос — SELECT * FROM table, вот соответственно и получается такая ситуация, писали-бы там сразу SELECT col1, col2, col3 FROM table, или хотя-бы предупреждали-бы о минусах такого подхода — и было-бы таких ошибок меньше.
как типы данных (вернее их размерность) повлияет на скорость? можно прирост в цифрах?
Допустим есть у нас табличка только с числовыми полями, и мне надо вытащить оттуда второе поле из записи №3454324 — поскольку длина строки в таблице фиксирована, можно сразу сказать, из какой части файла читать, это практически мгновенное действие.
Когда все строки переменной длины (много text, varchar и т.д.) — будет замедление при больших таблицах.
Когда все строки переменной длины (много text, varchar и т.д.) — будет замедление при больших таблицах.
Косвенно =) меньший размер БД, меньший объем отдаваемых в выборке данных.
То есть если у нас есть поле «ICQ» типа VarChar, делать его длиннее 10 символов бессмысленноТ.е. когда у ICQ вместо десятизнаков появятся 11-ти(а это может произойти достаточно скоро) — вам надо будет об этом во-первых как-то узнать, во-вторых менять структуру БД, точнее менять размерность поля. На практике это означает, что вы узнаете об этом уже как о баге — вероятнее всего от пользователей вашего ресурса/приложения.
Это нехороший подход. Конечно не надо для ICQ делать varchar(255), но хотя бы какой то разумный запас оставлять надо я бы поставил хотя бы на несколько лет вперед varchar(12). Тем более, что с точки зрения производительности — разница мизерна
Сейчас вроде как хватает 9 знаков. 10 знаков UIN'а покроют все население Земли с запасом, тем более, что 100% интернетизация населения планеты ой как не скоро
Упс… чего то на меня поздяя ночь плохо подействовала сегодня — неправильно разряды посчитал, в чиселке 487299860 насчитал 10 знаков, извините меня :)
Насчет покрытия всего населения и интернетизации не совсем верно, не являясь злостным асечником, за свою жизнь зарегестрировал уинов 6-7. На работе практически весь состав офиса менял как минимум один раз аську за несколько лет, потому что меняли пароль, угодняли и пр.
Насчет покрытия всего населения и интернетизации не совсем верно, не являясь злостным асечником, за свою жизнь зарегестрировал уинов 6-7. На работе практически весь состав офиса менял как минимум один раз аську за несколько лет, потому что меняли пароль, угодняли и пр.
а что мешает сделать bigint вместо varchar и успокоиться?..
В MSSQL длина заявленной varchar на производительность либо не влияет, либо влияет так слабо, что я не смог это отследить.
Если в колонке varchar (10) и varchar (400) находятся строки по 10 символов — то скорость работы выборок и поиск по ним — не изменяется.
И в целом, рассказать о производительсноти MSSQL можно гораздо больше! Автор, исследуй вопрос!
Если в колонке varchar (10) и varchar (400) находятся строки по 10 символов — то скорость работы выборок и поиск по ним — не изменяется.
И в целом, рассказать о производительсноти MSSQL можно гораздо больше! Автор, исследуй вопрос!
А как же порядок таблиц? Ведь даже если в выборе 10, они соединяются по 2 и надо стараться что бы результаты на каждом шаге были минимальны :)
На счёт типов данных очень спорно:
varchat на то и var что не хранит пустые хвосты строк, в отличие от char, где строка занимает всегда один и тот же объём. Хотя, допускаю, что размерность varchar может влиять на размер индекса.
int имеет размерность машинного слова — т.е. обрабатывается по логике вещей быстрее. А если при сравнении будет преобразование типов происходить.
Короче, это всё очень сильно зависит от самого запроса и сути данных. Следование рекомендациям автора в ряде случаев наоборот замедлит работу.
varchat на то и var что не хранит пустые хвосты строк, в отличие от char, где строка занимает всегда один и тот же объём. Хотя, допускаю, что размерность varchar может влиять на размер индекса.
int имеет размерность машинного слова — т.е. обрабатывается по логике вещей быстрее. А если при сравнении будет преобразование типов происходить.
Короче, это всё очень сильно зависит от самого запроса и сути данных. Следование рекомендациям автора в ряде случаев наоборот замедлит работу.
Я и не претендовал на абсолютную применимость рекомендаций. Кстати, по записям типа char поиск идет быстрее, чем по varchar.
Про int и длину машинного слова: вы не учли объем памяти, который займет общая выборка. При обработке выборки объемом в несколько миллиардов записей уже приходится задумываться о нехватке оперативной памяти сервера — и экономить каждый байт.
Про int и длину машинного слова: вы не учли объем памяти, который займет общая выборка. При обработке выборки объемом в несколько миллиардов записей уже приходится задумываться о нехватке оперативной памяти сервера — и экономить каждый байт.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Повышение скорости работы SQL-запросов