|
|
Задавайте вопросы, мы ответим
Вы не зашли.
После
SET NAMES cp1251;
SET character_set_server=cp1251;
SELECT HEX("AB");
получаем: 4142, т.е. коды символов A и B.
А после
SET NAMES cp1251;
SET character_set_server=cp1251;
SELECT HEX("ЫЯ");
получаем: D0ABD0AF. Почему так?
Неактивен
У меня в Вашем примере так не получается (консоль koi8r).
mysql> SET NAMES cp1251;
Query OK, 0 rows affected (0.03 sec)
mysql> SET character_set_server=cp1251;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT HEX('ЫЯ');
+-----------+
| HEX('ЫЯ') |
+-----------+
| F9F1 |
+-----------+
1 row in set (0.00 sec)
Скорее всего консоль у Вас работает в UTF8. Вы задали SET NAMES cp1251, но передаете все равно символы в UTF8. Создайте таблицу в кодировке CP1251 и выполните HEX над полем таблицы. При этом SET NAMES следует установить в то значение, в котором работает клиент.
mysql> SET NAMES UTF8
mysql> CREATE TABLE tmpx (a varchar(10)) CHARSET=cp1251;
mysql> INSERT INTO tmpx VALUES ('ЫЯ');
mysql> SELECT * from tmpx;
mysql> SELECT HEX(a) from tmpx;
Неактивен
rgbeast, спасибо! И еще вопросик 
После
SELECT HEX(a1) & HEX(a2);
где a1 и a2 – строки, не превышающие 8 символов (т.е. max 64 бита).
Можно получить не верные значения, т.к. HEX возвращает шестнадцатеричные значения без префикса 0x. Выйти из положения можно, загромоздив запрос функцией CONV:
SELECT CONV(HEX(a1),16,10) & CONV(HEX(a2),16,10);
Но нельзя ли решить задачу более простым путем?
Премного благодарен
Неактивен
HEX возвращает строку, поэтому преобразование в любом случае необходимо, явное или неявное. Можно функцией CONCAT() добавить к началу строки '0x', но это будет более медленный путь, чем Ваш
Неактивен
rgbeast написал:
HEX возвращает строку, поэтому преобразование в любом случае необходимо, явное или неявное. Можно функцией CONCAT() добавить к началу строки '0x', но это будет более медленный путь, чем Ваш
Понятно, спасибо.
Неактивен
Кстати, вариант с использованием функции добавления к началу строки '0x' правильнее, т.к. CONV(“FFFFFFFFFFFFFFFF”,16,10) вернет 9223372036854775807 (7FFFFFFFFFFFFFFF) вместо правильного 18446744073709551615.
Неактивен
Продолжаю задавать вопросы
Раньше вместо запроса
SELECT (CONV(HEX(a1),16,10) & CONV(HEX(a2),16,10) = CONV(HEX(a3),16,10));
где a1, a2 и a3 – строки, не превышающие 8 символов (т.е. max 64 бита),
я использовал более громадный запрос, состоящего из ряда операций: [8 бит] & [8 бит] = [8 бит], … до тех пор, пока не исчерпаю все байты строк, участвующих в сравнении.
Я очень обрадовался, когда узнал, что операндами для ‘&’ могут быть 64-битные числа. Теперь ряд мелких операций, я заменил более емким вариантом: [64 бит] & [64 бит] = [64 бит].
Вопрос следующий:
Не выполняет ли MySQL операцию [64 бит] & [64 бит] = [64 бит], через ряд мелких, типа [8 бит] & [8 бит] = [8 бит]? Если это так, то получается, выигрыш в быстродействии от использования емкого варианта я не получу?! 
Неактивен
Нет, не выполняет. MySQL всегда выполняет действия над 64-битными числами, даже
на 32-битной системе. Более того, 8-битные Ваши вычисления он тоже выполняет по
64-битной арифметике 
Неактивен
Два вопроса:
1. Значит, перейдя на более емкий вариант запроса, я получаю выигрыш в быстродействии?
2. Как MySQL работает с 64-битными числами, если система 32-битная? Наверное, последовательно: сначала обрабатываются первые 32 бита числа, а потом вторые 32 бита числа. Или не так?
Огромный респект! Поистине это ценный ресурс
Неактивен
1. да, и даже в основном не из-за арифметики. Арифметика выполняется очень быстро. Преобразование строк и синтаксический анализ происходят на порядки медленнее. Поэтому лимитирующая операции - преобразование строки hex в число. Естественно эффективнее, когда это происходит один раз, а не несколько.
2. наверное так, хотя я не уверен, что она это делает для 8битовых чисел (чтобы ответить на вопрос, надо читать исходные коды MySQL), но согласно пунтку 1 это не важно
Неактивен
По поводу пункта два: так говорил Тобиас
По поводу того, как - это не важно Зависит от libc, там есть int64, который как-то умеет
считать, вот стандартные штуки там и есть, ничего особенного. Про порядок не могу сказать
ничего, но по логике сначала обрабатывается младшее число, потом старшее. Чтобы флаг
переноса в addc учесть Разумеется, по 32 бита.
Неактивен
