Форум пользователей MySQL

Например, индекс будет по-умолчанию того же размера, что и определение VARCHAR().

Эксперимент показал, что нулями дописывать не будет, по крайней мере при хранении на диске в MyISAM. Возможно, при использовании он дописывает нулями в памяти

А если длина будет больше 255, то все равно не влезет. Индекс никто не запрещает делать только на начало колонки, чтобы не было проблем из-за его излишней длины - это совершенно очевидно, что часть алгоритмов используют индекс как запись фиксированного размера, хотя не посмотрев в исходники точно сказать какие именно не получится.

Ну, вспомни еще про таблички MEMORY тогда. Они хранят их как CHAR().

Ну, ты бы и сам мог проверить

[aurica] root test > create table a (a varchar(255));
Query OK, 0 rows affected (0.36 sec)

[aurica] root test > insert a values ('blah');
Query OK, 1 row affected (0.00 sec)

[aurica] root test > create table b select * from a;
Query OK, 1 row affected (0.06 sec)
Records: 1  Duplicates: 0  Warnings: 0

[aurica] root test > alter table b engine=memory;
Query OK, 1 row affected (0.07 sec)
Records: 1  Duplicates: 0  Warnings: 0

[aurica] root test > show create table b;
+-------+-----------------------------------------------------------------------------------------+
| Table | Create Table                                                                            |
+-------+-----------------------------------------------------------------------------------------+
| b     | CREATE TABLE `b` (
  `a` varchar(255) DEFAULT NULL
) ENGINE=MEMORY DEFAULT CHARSET=utf8 |
+-------+-----------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

[aurica] root test > show table status like 'b'\G
*************************** 1. row ***************************
           Name: b
         Engine: MEMORY
        Version: 10
     Row_format: Fixed
           Rows: 1
Avg_row_length: 768
    Data_length: 129696
Max_data_length: 16690176
   Index_length: 0
      Data_free: 0
Auto_increment: NULL
    Create_time: NULL
    Update_time: NULL
     Check_time: NULL
      Collation: utf8_general_ci
       Checksum: NULL
Create_options:
        Comment:
1 row in set (0.00 sec)

Если ты внимательно посмотришь на вот это, то обнаружишь, что там считаются
только внутренние временные таблицы, т.е. те, которые используются, например,
при большом join без индексов.

Так UTF8, три байта, 256*3 = 768
А память выделяется страничками, тут уж никуда не денешься.

Я вставлял именно blah. Мог бы вставить blahminor, размер бы не поменялся. Вопрос
на понимание: почему? Кажется, ты путаешь некоторые размеры

Страничка — это некоторый блок памяти, работа с которым идет атомарным образом.
Просто удобный способ работы с данными. Допустим, у тебя есть твой шаблонизатор.
Для того, чтобы распарсить какой-то блок, ты берешь всю структуру загруженных
шаблонов и работаешь с ней. Если бы твое приложение было многопоточным (например,
держало все шаблоны в памяти), то тебе приходилось бы ставить mutex на обращении
к дереву. Потом бы ты обнаружил, что блокировка всего дерева неэффективна, т.к.
это эффективно сводит многопоточное приложение к однопоточной работе. Ты решишь
брать mutex на куски деревьев. Потом этого мало и ты решишь, что надо блокировать
куски кусков — странички

1. Кодировка utf8: 1-3 байта на символ.
2. VARCHAR(255): 0-255 символов для хранения информации + 1 символ для
    хранения живой длины строки
3. Переделываем в MEMORY и 2 пункт эффективно выделяет полную память
    в 256 * 3 байт. Вне зависимости от того, что там хранится.

--

Ну, так есть, например, в BDB. В InnoDB пошли еще дальше и ставят
блокировки на строки (а страничка стала некоторым атомарным куском в
таблице; например, если ты меняешь данные на страничке одной транзакцией
при том, что другие транзакции находятся в уровне изоляции выше, чем
READ UNCOMMITTED и читали эту страничку, страничка дублируется и
изменения применяются к дублю), но оперируются данные все равно
постранично, т.к. это удобно.