Форум MySQL

1) какой тип таблицы и какие типы полей лучше использовать в динамических таблицах???
т.е. когда размеры не имеют значения... говорят, VARCHAR медленный...

2) какая разница между индексами их же несколько видов...
например, у меня 2 таблицы. индексы служат для связи таблиц...
в одной первичный ключ,
а во второй простой индекс...
если я во второй поставлю УНИКАЛ. индекс. он будет быстрее???

3) говорят, желательно, ставить ограничения при создании индексов...

например, в одно поле я записываю СИД-сессии. т.е. он уникальный..
и какой поиск будет быстрее?
- если я поставлю уникал. индексацию
или
- если поставлю с ограничением обычный индекс
т.е. индексироваться будет только несколько 1ых значений...

4) Многостолбцовые индексы, говорят они очень сильно ускоряют выборку...
он как ассоц. массивы.. - это так???

т.е. если у меня 3 поля col1,col2,col3
то подобная индексация index(col1,col2,col3) ускорит выборку,
только если будем искать по порядку??? или нет?

и еще если надо будет найти только col1,col3 - без 2 поля, скорость будет такая же???

5) как можно сжать данные в одном поле?
т.е. например, когда делаем "Личный сообщения"...
поиск по сообщениям, думаю, не надо делать,
поэтому можно их хранить в БД. в сжатом виде...
поле должно быть бинарным.. а как сделать сжатие??
через PHP или есть функции в Мускуле? или.. еще как то?

UP
///
хоть на несколько вопрос ответьте... =)

>1) какой тип таблицы и какие типы полей лучше использовать в динамических таблицах???
>т.е. когда размеры не имеют значения... говорят, VARCHAR медленный...

кто говорит и что говорит?

Говорят не что varchar медленный, а что обработка таблиц, строки которой имеют нефиксированную длину, несколько замедляется из-за необходимости обращения к кластерному индексу.
CHAR быстрый не сам по себе, а лишь в том смысле, когда в таблице нет вообще ни одного varchar'a, text'a blob'a и прочее. Более того, если они таки есть, то любой char длиннее 2-х символов автоматически будет заменен на varchar, поскольку запись УЖЕ имеет переменную длину, и экономить скорость на фиксированных полях УЖЕ не выйдет.


>2) какая разница между индексами их же несколько видов...
>например, у меня 2 таблицы. индексы служат для связи таблиц...
>в одной первичный ключ,
> а во второй простой индекс...
>если я во второй поставлю УНИКАЛ. индекс. он будет быстрее???


Уникальный индекс явно определяет, что повторов соответствующего ключа не будет, и на этом можно строить поиск более оптимально.

В простом индексе повторы допустимы. К примеру в случае простого индекса ключи вообще у всех строк таблицы могут быть одинаковыми.
При уникальном индексе могут повторяться только NULL (если NULL-признак вообще можно назвать значением)
Первичный ключ по определению уникален, и по определению же не допускает NULL.

>3) говорят, желательно, ставить ограничения при создании индексов...
>
>например, в одно поле я записываю СИД-сессии. т.е. он уникальный..
>и какой поиск будет быстрее?
>- если я поставлю уникал. индексацию
>или
>- если поставлю с ограничением обычный индекс

если Вы ставите ограничение на уникальный индекс, то следовательно тем самым будете требовать уникальность не всей строки а лишь левой её части. Уверены ли Вы что первые N символов SID у Вас будут уникальны?

>т.е. индексироваться будет только несколько 1ых значений...

не так! Не несколько первых значений, а несколько первых символов поля!


>4) Многостолбцовые индексы, говорят они очень сильно ускоряют выборку...
>он как ассоц. массивы.. - это так???

нет

>т.е. если у меня 3 поля col1,col2,col3
>то подобная индексация index(col1,col2,col3) ускорит выборку,

ускорит, если эта выборка будет следовать по условию WHERE col1=$v1 AND col2=$v2 AND col3=$v3
и замедлит вставки и модификации.

>только если будем искать по порядку??? или нет?
и ускорит если будет один из
SELECT... ORDER BY col1
SELECT... ORDER BY col1, col2
SELECT... ORDER BY col1, col2, col3
но не любой другой.


>и еще если надо будет найти только col1,col3 - без 2 поля, скорость будет такая же???

воспользоваться индексом не удастся.

>5) как можно сжать данные в одном поле?
>т.е. например, когда делаем "Личный сообщения"...
>поиск по сообщениям, думаю, не надо делать,
>поэтому можно их хранить в БД. в сжатом виде...
>поле должно быть бинарным.. а как сделать сжатие??
>через PHP или есть функции в Мускуле? или.. еще как то?

точно также как и при хранении вне БД.

>>1) какой тип таблицы и какие типы полей лучше использовать в динамических таблицах???
>>т.е. когда размеры не имеют значения... говорят, VARCHAR медленный...

> кто говорит и что говорит?
общая информация, всяких статей и тем на форумах

>Говорят не что varchar медленный, а что обработка таблиц, строки которой имеют нефиксированную длину, несколько замедляется из-за необходимости обращения к кластерному индексу.
>CHAR быстрый не сам по себе, а лишь в том смысле, когда в таблице нет вообще ни одного varchar'a, text'a blob'a и прочее. Более того, если они таки есть, то любой char длиннее 2-х символов автоматически будет заменен на varchar, поскольку запись УЖЕ имеет переменную длину, и экономить скорость на фиксированных полях УЖЕ не выйдет.

хммм. а какие тогда поля имеют фиксир. длину для текста, кроме CHAR...?

я наверно, неправильно выразился...
таблица будет статистич. т.е. тот же онлайн...
и я хочу избавиться от полей имеющие нефиксир. длину...

пока переделал все на char, т.е. других типов полей нет.
но если надо будет больше 255 символов. ТО все char'ы уже будут как varchar?
может есть char с большей длиной? =)


и вот еще вопрос, если я использую многобайтовую кодировку (UTF-8),
как идет отношение к длине поля?
т.е. если тип CHAR(255) - я смогу записать 255 букв в кириллице?



остальные вопросы исчерпаны.
Благодарю, за подробный ответ...)

>пока переделал все на char, т.е. других типов полей нет.
>но если надо будет больше 255 символов. ТО все char'ы уже будут как varchar?
Будут. если больше двух. А не если больше 255.

>может есть char с большей длиной? =)
char в свежих версиях MySQL по-моему больше 255 байт. В разы.


>и вот еще вопрос, если я использую многобайтовую кодировку (UTF-8),
>как идет отношение к длине поля?
>т.е. если тип CHAR(255) - я смогу записать 255 букв в кириллице?

лишь 127.

> лишь 127
Нет, всё же 255, как показывает практика. Это кол-во символов, а не байтов.

Вот как?
Тогда каким образом такое поле хранится?
Там же ограничение на размер затраченной памяти в 1 + N байт?

> 1 + N байт
Так могло быть раньше. Сейчас же в VARCHAR можно хранить до 65535 байтов. Следовательно, они не могут в 1 байт впихнуть число > 255. Ведь этот один байт нужен для записи длины в VARCHAR.
Похоже действительно байты, но всё же благодаря новым лимитам хранить можно больше.

>Похоже действительно байты, но всё же благодаря новым лимитам хранить можно больше.

Вот в это верю. :)

>> 1 + N байт
>Так могло быть раньше. Сейчас же в VARCHAR можно хранить до 65535 байтов. Следовательно, они не могут в 1 байт впихнуть число > 255. Ведь этот один байт нужен для записи длины в VARCHAR.
>Похоже действительно байты, но всё же благодаря новым лимитам хранить можно больше.


что для Вас означает слово "сейчас"??? с какой версии??? подробнее, если можно =))

Что мешает заглянуть в документацию?

С версии 5.0.3
Но число хранимых русских символов все равно будет не больше чем половина указанной длины поля.
Так что VARCHAR(300) будет хранить лишь 150 русских букв (и вероятно, еще меньше китайских, японских, корейских и т.п.)

спасибо... =) значит, над ставить в 2 раза больше...

Вы не ответили на вопрос.

вопрос про документацию?

честно, говоря у меня с англ. неочень. ну, как и с русским в плане синтаксиса,
мне кажется я php лучше знаю, чем эти языки =) ну суть не в этом...

просто, я ищу инфу на русском, послед. что я нашел это
документация версии 5.0.3-alpha
но там как раз ничего не написано про увеличение памяти в полях...

там char(255), varchar(255), как и впредыдущих доках...

У меня в VARCHAR(300) влезает 300 русских символов. MySQL 5.0.45

русских UTF-8 ? :)

Я уже больше года других кодировок не использую:)

> Так что VARCHAR(300) будет хранить лишь 150 русских букв (и вероятно, еще меньше китайских, японских, корейских и т.п.)
300 - это мало, тут даже трех- четырехбайтовых символов 300 спокойно влезит. Вот 32767 многобайтовых уже не должно влезть.

Огромное спасибо... =) пошел творить...

На 4.1.22 в varchar более ~127 кириллистических в utf-8 записать не удавалось,насколько я помню..