Который быстрее: символ (1) или tinyint (1)? Почему?
МОЯ ПЛАТФОРМА:
PHP & mySQL
МОЯ СИТУАЦИЯ:
Я столкнулся с ситуацией, где я должен сохранить значение для пользовательского выбора в одном из моих столбцов таблицы. Теперь мои опции были бы к:
- Или объявите Столбец как символ (1) и сохраните значение как 'y' или 'n'
- Или объявите Столбец как tinyint (1) и сохраните значение как 1 или 0
- Этот столбец, так объявленный, может также быть индексирован для использования в рамках приложения.
МОИ ВОПРОСЫ:
Таким образом, я хотел знать, который из вышеупомянутых двух типов:
Приводит к более быстрой скорости запроса, когда к тому столбцу получают доступ (ради простоты, давайте не учтем смешивание других запросов или доступ к другим столбцам).
Самый эффективный способ сохранить и получить доступ к данным и почему?
Как скорость доступа варьируется, если столбцы индексируются и когда они не?
Мое понимание - то, что, так как символ (1) и tinyint (1) занимает только 1 байт места, пространство памяти не будет проблемой в этом случае. Затем то, что осталось бы, является скоростью доступа. Насколько я знаю, числовая индексация быстрее и более эффективна, чем что-либо еще. Но случай здесь является жестким для решения, я думаю. Определенно хотел бы услышать Ваш опыт в этом.
Заранее спасибо.
8 ответов
на основе псевдокода tvanfosson, вот что я придумал в javascript:
var ELEMENT_NODE = 1;
var TEXT_NODE = 3;
function normalize(node) {
for (i=0; i<node.childNodes.length; i++) {
var child = node.childNodes[i];
if (child.nodeType == ELEMENT_NODE) {
normalize(child);
continue;
}
if (child.nodeType != TEXT_NODE) { continue; }
var next = child.nextSibling;
if (next == null || next.nodeType != TEXT_NODE) { continue; }
var combined_text = child.nodeValue + next.nodeValue;
new_node = node.ownerDocument.createTextNode(combined_text);
node.insertBefore(new_node, child);
node.removeChild(child);
node.removeChild(next);
i -= 1;
}
}
Uhh Jason, TCP не использует UDP. TCP использует IP, поэтому его часто называют TCP/IP. UDP также использует IP, поэтому UDP технически является UDP/IP. Уровень IP обрабатывает передачу данных от конца к концу (через различные сети), поэтому он называется протоколом межсетевого взаимодействия . TCP и UDP обрабатывают сегментирование самих данных. Нижние уровни, такие как Ethernet или PPP или любые другие, которые используются для передачи данных между компьютерами (то есть в пределах одной сети).
-121--1231323- Я думаю, что вы должны создать столбец с ENUM ('n', 'y') . Mysql сохраняет этот тип оптимальным путь. Это также поможет сохранить в поле только допустимые значения.
Вы также можете сделать его более дружественным для человека ENUM («нет», «да») без влияния на производительность. Поскольку последовательности 'нет' и 'да' хранятся только один раз в определении ENUM . Mysql хранит только индекс значения на строку.
Также обратите внимание на сортировку по столбцу ENUM :
значения ENUM сортируются в соответствии с порядком, в котором элементы перечисления были перечислены в спецификации столбца. (Другими словами, значения ENUM сортируются в соответствии с их индексными номерами.) Например, «a» сортирует перед «b» для ENUM («a» «, b»), но «b» сортирует перед «a» для ENUM («b» «, a»).
Использование миниатюр является более стандартной практикой, и позволит вам легче проверять значение поля.
// Using tinyint 0 and 1, you can do this:
if($row['admin']) {
// user is admin
}
// Using char y and n, you will have to do this:
if($row['admin'] == 'y') {
// user is admin
}
Я не эксперт во внутренней работе MySQL, но интуитивно чувствую, что поиск и сортировка целочисленных полей быстрее, чем символьных (у меня просто возникает ощущение, что 'a' > 'z' - это больше работы, чем 0 > 1), и кажется, что я чувствую себя гораздо более знакомым с вычислительной точки зрения, в которой 0s и 1s - стандартные флаги включения/выключения. Таким образом, хранилище для целых чисел, кажется, лучше, чувствуется приятнее, и его легче использовать в логике кода. 0/1 - явный победитель для меня.
Вы также можете заметить, что в какой-то степени это официальная позиция MySQL, также из их документации:
BOOL, BOOLEAN: Эти типы являются синонимами для ТИНИИНТ(1). Значение нуля считается фальшивым. Ненулевыми значениями являются считается верным.
Если MySQL зайдет так далеко, что приравнят TINYINT(1) к BOOLEAN, то, похоже, так и будет.
.Чтобы знать это наверняка, нужно сравнить его с эталоном. Или знайте, что это, скорее всего, не будет иметь такого большого значения в более градусном представлении всего проекта.
Столбцы символов имеют кодировки и столбцы, и их сравнение может привести к ненужным переключениям между кодировками, так что я думаю, что int будет быстрее. По той же причине я думаю, что обновление индекса в столбце int также происходит быстрее. Но опять же, это не будет иметь большого значения.
CHAR может занимать более одного байта, в зависимости от выбранного вами набора символов и опций таблицы. Некоторые символы могут занимать три байта для кодирования, поэтому MySQL иногда резервирует этот пробел, даже если вы используете только y и n.
TINYINT 1 Byte
CHAR(M) M Bytes, 0 <= M <= 255
есть разница?
Они оба будут настолько близки, что это не имеет значения. Если вы чувствуете, что должны задать этот вопрос по SO, вы слишком оптимизируете. Используй то, что имеет самый логичный смысл.
Если вы укажете типы BOOL или ] BOOLEAN в качестве типа столбца при создании таблицы в MySQL создает тип столбца как TINYINT (1) . Предположительно это самый быстрый из двух.
Также:
Мы намерены реализовать полное логическое тип обработки, в соответствии с стандартный SQL, в будущем MySQL релиз.
Rate insert tinyint(1) insert char(1) insert enum('y', 'n')
insert tinyint(1) 207/s -- -1% -20%
insert char(1) 210/s 1% -- -19%
insert enum('y', 'n') 259/s 25% 23% --
Rate insert char(1) insert tinyint(1) insert enum('y', 'n')
insert char(1) 221/s -- -1% -13%
insert tinyint(1) 222/s 1% -- -13%
insert enum('y', 'n') 254/s 15% 14% --
Rate insert tinyint(1) insert char(1) insert enum('y', 'n')
insert tinyint(1) 234/s -- -3% -5%
insert char(1) 242/s 3% -- -2%
insert enum('y', 'n') 248/s 6% 2% --
Rate insert enum('y', 'n') insert tinyint(1) insert char(1)
insert enum('y', 'n') 189/s -- -6% -19%
insert tinyint(1) 201/s 7% -- -14%
insert char(1) 234/s 24% 16% --
Rate insert char(1) insert enum('y', 'n') insert tinyint(1)
insert char(1) 204/s -- -4% -8%
insert enum('y', 'n') 213/s 4% -- -4%
insert tinyint(1) 222/s 9% 4% --
кажется, что по большей части enum('y', 'n') быстрее вставляется.
Rate select char(1) select tinyint(1) select enum('y', 'n')
select char(1) 188/s -- -7% -8%
select tinyint(1) 203/s 8% -- -1%
select enum('y', 'n') 204/s 9% 1% --
Rate select char(1) select tinyint(1) select enum('y', 'n')
select char(1) 178/s -- -25% -27%
select tinyint(1) 236/s 33% -- -3%
select enum('y', 'n') 244/s 37% 3% --
Rate select char(1) select tinyint(1) select enum('y', 'n')
select char(1) 183/s -- -16% -21%
select tinyint(1) 219/s 20% -- -6%
select enum('y', 'n') 233/s 27% 6% --
Rate select tinyint(1) select char(1) select enum('y', 'n')
select tinyint(1) 217/s -- -1% -4%
select char(1) 221/s 1% -- -2%
select enum('y', 'n') 226/s 4% 2% --
Rate select char(1) select tinyint(1) select enum('y', 'n')
select char(1) 179/s -- -14% -20%
select tinyint(1) 208/s 17% -- -7%
select enum('y', 'n') 224/s 25% 7% --
Хотя я предполагаю, что индекс в TINYINT будет быстрее, чем индекс в CHAR (1) из-за отсутствия накладных расходов на обработку строк (сопоставление, пробелы и т. Д.), У меня нет любые факты, подтверждающие это. Я предполагаю, что нет существенной разницы в производительности, о которой стоит беспокоиться.
Однако, поскольку вы используете PHP, хранение в формате TINYINT имеет гораздо больший смысл. Использование значений 1/0 эквивалентно использованию true и false , даже когда они возвращаются в PHP как строки и могут обрабатываться как таковые. Вы можете просто выполнить if ($ record ['field']) с вашими результатами в качестве логической проверки вместо постоянного преобразования между 'y' и 'n'.