- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
У меня таблицы в ФИО, тип поля varchar 255, я проавильно понимаю что значение 255 избыточно и при сильной нагрузке может увеличивать время запроса к этой базе?
лучше уменьшить до 64 ?
Вот есть статья сравнения VARCHAR(8000) и VARCHAR(MAX)
http://rusanu.com/2010/03/22/performance-comparison-of-varcharmax-vs-varcharn/
Чуть влияет...
Не будет никакой разницы с 255 или 64. Теоретически намерять то наверное можно, но на практике нет.
Разница очень несущественна. Я бы ничего не менял
Вот есть статья сравнения VARCHAR(8000) и VARCHAR(MAX)
varchar(max) это вроде микрософт sql server. mysql такое не может, там максимум varchar(21844) при CHARACTER SET utf8. Либо использовать text.
ТС, переходите на postgresql, там varchar без обязательного лимита :)
---------- Добавлено 15.12.2017 в 21:36 ----------
Не будет никакой разницы с 255 или 64.
Разница будет по потреблению памяти в случае, если тип таблицы - временная (создается при сортировках) или memory.
Очень расплывчатое понятие "сильная нагрузка". У вас в таблице БД что, сотни тысяч записей чтобы SELECT\Update запросы тормозили?
Если нет - то вы разницу даже с синтетическими тестами не особо заметите.
Разница конечно есть, но она несущественна. Лучше оптимизируйте код или запросы.
Разница будет по потреблению памяти в случае, если тип таблицы - временная (создается при сортировках) или memory.
Ну это же не char, не будет такого большого оверхеда. Вообще проблемы обычно из за индексов, кривых запросов и т.п., но из за длинны варчар поля - еще не слышал :)
Есть таблица Иннод с ФИО примерно 400.000 записей и там 8 полей varchar 255. Некоторые запросы к этой таблице чуток подтормаживают.
Запросы к базе в будни примерно 400 в сек.
А ради уменьшения веса таблицы стоит уменьшить 255 до 64 ?
Ну это же не char, не будет такого большого оверхеда.
Во временных таблицах и таблицах в памяти mysql выделяет место с фиксированными размером колонки. Т.е. разница по потреблению памяти между таблицей с varchar(255) и varchar(64) будет четырехкратной.
---------- Добавлено 15.12.2017 в 22:23 ----------
А ради уменьшения веса таблицы стоит уменьшить 255 до 64 ?
Зависит от версии mysql и настроек. Т.к. innodb (когда-то) использовал ограниченный размер индекса (755 байт кажется или около того), то с индексацией полей varchar(255) в utf8 могли быть проблемы. На самом деле быстрее проверить, чем спрашивать.
Базу в дамп и проверить на практике. Тормозить что угодно может, причин миллион. Вес таблицы на выборку не особо влияет. Тем более что варчар - это динамическая длинна, а не статическая. Ну выиграется пара байт за запись, не бог весь какой гешефт.
У меня таблицы в ФИО, тип поля varchar 255, я проавильно понимаю что значение 255 избыточно и при сильной нагрузке может увеличивать время запроса к этой базе?
лучше уменьшить до 64 ?
Для varchar разницы нет (если длиннее 4 символов).
Разница будет только для char, в меру другого (чем у варчар) способа его хранения
---------- Добавлено 15.12.2017 в 22:28 ----------
ТС, переходите на postgresql, там varchar без обязательного лимита :)