Вопросы по оптимизации БД. Типы данных

Тема в разделе "Базы данных", создана пользователем yeaahhh, 20 мар 2015.

Статус темы:
Закрыта.
Модераторы: latteo
  1. yeaahhh

    yeaahhh

    Регистр.:
    8 май 2008
    Сообщения:
    278
    Симпатии:
    11
    Ребят, изучаю оптимизацию БД, извиняюсь за дилетантство..
    Был бы благодарен, если бы кто-нибудь помог устаканить некоторые вопросы(много прочитал, хотелось бы все собрать в кучу и получить уверенность, что правильно все понял:(

    1) Всегда необходимо указывать столбцу минимально-возможный тип данных?
    пример: для id primary key, если не планируется более 65 000 записей, нужно ставить smallint(5) unsigned?
    поле с id-товарами: если знаю, что товаров не более 255 будет, ставить tinyint(3) unsigned?
    2) Для значений флагов в БД (1,0) оптимален tinyint(1) (он же bool)? enum не стоит(если 2 значения, он будет 2 байта жрать?)?
    3) Для текстового поля (например: описание товара) оптимален text? но, что если я знаю, что текст не будет более 2 000? я могу поставить varchar (2000)? varchar же меньше байт потребляет?
    4) Есть поле в БД, которое все время пустое и оно не нужно(готовый движок переделываю под себя, очень много править нужно, чтобы его удалить, пока нет времени). Какой тип данных разумнее сделать? char(0)?
    5) Тип Varchar потребляет памяти исходя из длины значения в поле или то, что указывается при создании - Varchar(2000)?

    Просто вчера вечером придерживался вышеуказанным правилам и наоптимизировал БД так, что по статистике хостинга, нагрузка в кол-ве времени обработки запросов возросла.. А делал вот что: было id(11) primary key -> стало smallint(5) unsigned, были varchar(3333) -> стало varchar(2000), int(1) -> tinyint(1) unsigned
    Вроде все верно же?
    Заранее огромное спасибо. Хочется ясности..)
     
    Последнее редактирование: 20 мар 2015
  2. Q_BASIC

    Q_BASIC

    Регистр.:
    30 ноя 2013
    Сообщения:
    352
    Симпатии:
    223
    Так всё правильно, но максимальное значение у типа VARCHAR это 255 символов, не получится varchar(2000), 33333 и т.д.
    У TEXT максимальное значение это 65535

    http://habrahabr.ru/post/36868/
     
  3. latteo

    latteo Эффективное использование PHP, MySQL

    Moderator
    Регистр.:
    28 фев 2008
    Сообщения:
    1.402
    Симпатии:
    1.183
    Хабр тут не показатель, хотя я тоже был уверен, что varchar ограничен 255 символами, ан нет: The length can be specified as a value from 0 to 255 before MySQL 5.0.3, and 0 to 65,535 in 5.0.3 and later versions.
    http://dev.mysql.com/doc/refman/5.0/en/char.html

    Запусти OPTIMIZE TABLE http://dev.mysql.com/doc/refman/5.1/en/optimize-table.html

    Вроде бы все выборы были сделаны правильно, по крайней мере именно так учат :)
    Поставив перед собой задачу оптимизации - я прогоняю всё множеством тестов. Это ведь не так сложно сделать 2 таблицы с одинаковыми данными и различными типами полей и выполнить по 1000 типовых SQL-запросов с каждой, только кеш БД отключи или слегка меняй запрос для каждой итерации и данные выбирай из разных частей таблицы, если это актуально для движка.
     
    Последнее редактирование: 21 мар 2015
    yeaahhh нравится это.
  4. konov

    konov Писатель

    Регистр.:
    2 мар 2015
    Сообщения:
    8
    Симпатии:
    3
    зачем так замарачиваться???

    делайте универсально, вдруг у вас больше 65000 записей будет? - я ставлю bigint primary key и не парюсь вообще.
    текстовые поля, тоже непонятно, если вы точно уверены, что количество символов не будет превышать, к примеру - 200 знаков, то ставьте - varchar(200), а чтобы не париться и хранить большое количество инфы, то ставьте varchar(max)
    если поле булевое, просто int.

    стандартизация лучше, чем городить городуху с типами данных. При стандартизации, у вас во всех таблицах, поля будут одинаковые, а если каждую таблицу так продумывать, то вы можете потом нарваться на множество сложностей, к примеру в поле char(0) вдруг понадобиться что-то вставить большое, ан не будет получаться. геморой.
    Лучше оптимизировать код.
     
  5. dima_8_16_80

    dima_8_16_80 Постоялец

    Регистр.:
    1 фев 2012
    Сообщения:
    107
    Симпатии:
    23
    Действительно, лучше оптимизировать не БД, а запросы к ней. Часто лучше добавить даже лишние поля в таблицы и это немного увеличит место на диске, зато сократит нагрузку на сервер при работе запросов. Если записей будет 60000 и простая таблица с простыми запросами - это тьфу для сервера. Какая разница, 0.0046 секунд выполняется запрос, или 0.0052?
    А вот если запросы сложные, со связями, циклами, да еще и параллельных запросов много, тут уже да, можно смотреть. Включать профилирование и смотреть. Находить долгие запросы, оптимизировать их, ставить индексы.
    А на начальном этапе не заморачивайтесь.
     
Статус темы:
Закрыта.