2010-10-29 15 views
7

Bunun için bir açıklama göremiyorum ve daha önce beklendiği gibi çalıştığından eminim.-1 döndürme MySQL döküm 18446744073709551615

SELECT CAST(-1 AS UNSIGNED INTEGER); 

Beklenen: 0
Sonuç: 18446744073709551615

şey değişti veya bu MySQL hata olduğunu?

[GÜNCELLEME] Tamam, ben daha önce çalışmak için çıkmıştı neden bir sebep buldum düşünüyorum

:? .. ​​Bu neden olduğunu

Şimdi
SELECT CAST(-1.0 AS UNSIGNED INTEGER); 
+--------------------------------+ 
| CAST(-1.0 AS UNSIGNED INTEGER) | 
+--------------------------------+ 
|        0 | 
+--------------------------------+ 

, birisi farkını açıklayabilir misiniz Aslında ben buldum Dokümanlar içinde! ya da işlenen bir kayan nokta değeri ise

, sonuç kayan nokta değerdir ve önceki kural tarafından etkilenmez. docs itibaren

+0

'SELECT CAST (-1.0 UNSIGNED INT olarak);' bir uyarı verir (uyarıların görünmesi için önce 'uyarıları 'çalıştırın):" Hata (Kod 1292): Kesik yanlış DECIMAL değeri:' '". – Lekensteyn

+0

@Lekensteyn: Uyarı, uyarı verildiği için, kılavuzun bu yana biraz kafa karıştırıcı olmasına rağmen, "Bu bağlamda, DECIMAL sütun değerleri kayan nokta değerleri olarak kabul edilir." – Cez

cevap

10

:

MySQL imzalı ve imzasız hem 64 bit değerleri ile aritmetik destekler. Sayısal operatörler (örneğin, + veya -) kullanıyorsanız ve işlenenlerden biri işaretsiz bir tam sayı ise, sonuç varsayılan olarak işaretsizdir (bkz. Bölüm 11.6.1, “Aritmetik İşleçleri”). Sırasıyla imzalı veya imzasız bir 64 bit tam sayıya değer atamak için SIGNED veya UNSIGNED cast operatörünü kullanarak bunu geçersiz kılabilirsiniz. Eğer döküm ile 0xFFFFFFFFFFFFFFFF nasıl davranacağını

mysql> SELECT CAST(1-2 AS UNSIGNED) 
     -> 18446744073709551615 
mysql> SELECT CAST(CAST(1-2 AS UNSIGNED) AS SIGNED); 
     -> -1 

Temel olarak, MySQL söyle. İmzalandığında -1, imzasız olduğunda 18446744073709551615.

+7

'18446744073709551615' tam olarak 2^64-1’dir. Başka bir çıktı beklemezdim. –

+0

& Álvaro G. Vicario: Açıklamalar için teşekkürler – Cez