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

Статус
В этой теме нельзя размещать новые ответы.

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
Вроде все верно же?
Заранее огромное спасибо. Хочется ясности..)
 
Последнее редактирование:
Так всё правильно, но максимальное значение у типа VARCHAR это 255 символов, не получится varchar(2000), 33333 и т.д.
У TEXT максимальное значение это 65535

Для просмотра ссылки Войди или Зарегистрируйся
 
Так всё правильно, но максимальное значение у типа VARCHAR это 255 символов, не получится varchar(2000), 33333 и т.д.
У TEXT максимальное значение это 65535

Для просмотра ссылки Войди или Зарегистрируйся
Хабр тут не показатель, хотя я тоже был уверен, что 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.
Для просмотра ссылки Войди или Зарегистрируйся

Просто вчера вечером придерживался вышеуказанным правилам и наоптимизировал БД так, что по статистике хостинга, нагрузка в кол-ве времени обработки запросов возросла..
Запусти OPTIMIZE TABLE Для просмотра ссылки Войди или Зарегистрируйся

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

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
Вроде все верно же?
Заранее огромное спасибо. Хочется ясности..)

зачем так замарачиваться???

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

стандартизация лучше, чем городить городуху с типами данных. При стандартизации, у вас во всех таблицах, поля будут одинаковые, а если каждую таблицу так продумывать, то вы можете потом нарваться на множество сложностей, к примеру в поле char(0) вдруг понадобиться что-то вставить большое, ан не будет получаться. геморой.
Лучше оптимизировать код.
 
Действительно, лучше оптимизировать не БД, а запросы к ней. Часто лучше добавить даже лишние поля в таблицы и это немного увеличит место на диске, зато сократит нагрузку на сервер при работе запросов. Если записей будет 60000 и простая таблица с простыми запросами - это тьфу для сервера. Какая разница, 0.0046 секунд выполняется запрос, или 0.0052?
А вот если запросы сложные, со связями, циклами, да еще и параллельных запросов много, тут уже да, можно смотреть. Включать профилирование и смотреть. Находить долгие запросы, оптимизировать их, ставить индексы.
А на начальном этапе не заморачивайтесь.
 
Статус
В этой теме нельзя размещать новые ответы.
Назад
Сверху