- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Здравствуйте.
Скажу честно, используя MySQL регулярно, его изучение я обошел стороной. Когда я читал о типах данных, для себя решил, что буду использовать для всех чисел INT, для всех кратких надписей VARCHAR, для всех длинных тестов TEXT.
Мне интересно, как это сказывается на производительности. По сути, да, больше ОЗУ нужно для кеша. Но влияет ли это на производительность? Если формально для типа INT резервируются 4 кбайта памяти, сколько данных пересылается по протоколу TCP? 4 кбайт (с кучей нулей) или реальный размер поля?
Уточняете ли вы размер числа (TINY, SMALL, MEDIUM) в своих проектах? Для чего вы это делаете?
Какие минусы обычного INT, какие минусы строгой типизации?
Мысли вслух. По сути. У меня много ОЗУ (подходит INT). Мне не нужна совместимость с другими SQL СУБД (MS, Postgre) (подходит TINY, SMALL, ...). Но я хочу правильно, хочу точно. Вообще, я склоняюсь к строгой типизации в SQL, но ... следовательно нужно добавлять оную и в клиент. Так вот например, если я задал для автоинкремента тип SMALLINT, а он у меня уже заполнился, я должен убедиться в том что у меня есть свободные ячейки, перед тем как дать возможность добавить новую запись через WEB интерфейс.
Минусы обычного INT, когда Вам в базе нужно хранить булевое значение в том, что INT выжирает больше памяти. Используйте, например, tinyint(1) и так далее.
Тут нужно отталкиваться конкретно от задачи.
http://dev.mysql.com/doc/refman/5.5/en/storage-requirements.html
для типа INT резервируются 4 к байта памяти
Откуда информация?
я должен убедиться в том что у меня есть свободные ячейки, перед тем как дать возможность добавить новую запись через WEB интерфейс.
Валидация должна быть в любом случае. о_О
Строго говоря, и в случае с INT возможно переполнение.
Формально, использование Unsigned tinyInt вместо Int даёт экономию в 3 байта на запись, но потенциальную возможность быстрого заполнения автоинкремента.
Если в таблице не планируется много записей - можно "экономить", однако, "в случае чего" очень бредово отлавливать "тихую" ошибку переполнения (в зависимости от драйвера MySQL может вместо отправленного большого значения записать максимально допустимое для поля значение)...
для всех длинных тестов TEXT.
Для некоторых текстов маловато - LONGTEXT / MEDIUMTEXT может потребоваться..
CHAR иногда может иметь преимущество перед VARCHAR (заранее известная длина строки -> позиционирование курсора)
> Если формально для типа INT резервируются 4 кбайта памяти, сколько данных пересылается по протоколу TCP? 4 кбайт (с кучей нулей) или реальный размер поля?
INT - 4 байта.
INT - 4 байта.
Ой да, извините, это опечатка.
А ведь и правда. Спасибо.
---------- Добавлено 08.07.2013 в 22:50 ----------
Тут нужно отталкиваться конкретно от задачи.
Ну вопрос в том, а стоит ли? Мне не жалко ОЗУ, мне жалко времени. Это ведь как-то потенциально может влиять на производительность? 4 байта на INT, а пакет содержит в себе статически 4 байта, или пакет данных занимает ровно столько сколько нужно, без заполнения нулем?
Мне не жалко ОЗУ, мне жалко времени.
Не буду оригинальничать.. в очередной раз предложу прогнать бенчи..
:)
Причём, для тестируемых типов с использованием индексов и без них..
Было бы неплохо сохранить SQL на случай, если возникнет желание воспроизвести на другом сервере, поиграться с настройками, добавить тестов.
В таком виде, например... или в более "дружелюбном".
А я храню в ENUM(0, 1). Так плохо?
А я храню в ENUM(0, 1). Так плохо?
В производительности и ОЗУ не потеряете ничего. Разница только одна - на случай каких-либо математических функций tinyint предпочтительнее.
Однозначно третий вариант. Под каждую задачу свой тип.
При больших объемах занимаемое данными место и, главное, скорость работы может очень отличаться в зависимости от выбора типа. Мой подход противоположен подходу "памяти не жалко". Всегда считал, что в первую очередь нужно оптимизировать архитектуру/код, а уже потом добавлять железо.
Если формально для типа INT резервируются 4 кбайта памяти, сколько данных пересылается по протоколу TCP? 4 кбайт (с кучей нулей) или реальный размер поля?
Тут еще один момент: использование tcp при работе через порт - сразу минус около 10% производительности по сравнению с работой через сокет.
---
Виктор