Det är faktiskt inget fel med din första fråga, syntaktisk är den perfekt som det här fungerade exemplet visar.
mysql> SET @@SESSION.block_encryption_mode = 'aes-256-cbc';
mysql> create table MyTable(
-> Encrypted_ID varbinary(256),
-> InitializationVector_iv varbinary(16)
-> );
Query OK, 0 rows affected (0.93 sec)
mysql> SET @iv = RANDOM_BYTES(16);
Query OK, 0 rows affected (0.00 sec)
mysql> INSERT INTO MyTable SET Encrypted_ID = AES_ENCRYPT('hello','key', @iv), InitializationVector_iv = @iv;
Query OK, 1 row affected (0.17 sec)
mysql> SELECT CAST(AES_DECRYPT(Encrypted_ID,'key', InitializationVector_iv) AS CHAR) from MyTable;
+------------------------------------------------------------------------+
| CAST(AES_DECRYPT(Encrypted_ID,'key', InitializationVector_iv) AS CHAR) |
+------------------------------------------------------------------------+
| hello |
+------------------------------------------------------------------------+
1 row in set (0.00 sec)
När det gäller varför det inte fungerar, lyckades jag få frågan att returnera NULL i 2 scenarier. En, du får NULL tillbaka om du använder en annan iv för kryptering och dekryptering, så du kanske vill titta på hur du lagrar som iv. Två, du får NULL där du har variabeln block_encryption_mode inställd på ett annat sätt när du lagrar och försöker hämta värdet, kontrollera att du inte av misstag återgår till standardinställningen 'aes-128-ebc mellan sessioner. Det kan finnas andra...
Den andra frågan kommer att misslyckas eftersom du behöver förse iv till både krypterings- och dekrypteringsfunktionerna, du använder den bara för att kryptera. Dessutom, eftersom du tar värdena från MyTable, kommer Encrypted_ID redan att vara krypterad och effekten av denna fråga skulle vara att kryptera den igen, innan du vänder på det för att få dig tillbaka till det lagrade (krypterade) värdet.
Slutligen kommer AES bara att använda 16 byte av iv så du kan lika gärna göra det VARBINARY(16).