You can increase the maximum InnoDB index prefix size in MySQL 5.6 to 3072 bytes by setting `innodb_large_prefix` to `ON` along with other settings that you'll also need in order to enable that one, discussed here:

http://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_large_prefix

These changes should allow these indexes to be valid for InnoDB tables.

With a character set of (I assume) `utf8`, a `VARCHAR(1024)` would need 1024 x 3 = 3072 bytes for its index.

----

Updates:

I incorrectly showed the value of the variable as `Yes` when it should have been `ON`.  

But also:

> *I think it needs 3072+2 – [ypercube][1]*

When I thought about this, it sounded correct, because 1 byte is needed to store the size of the value when the value is 255 bytes or less, and 2 bytes are needed otherwise.

However, testing reveals that this isn't the case, in this case -- InnoDB using the `COMPRESSED` row format from [Barracuda][2] can actually index the full size of a `VARCHAR(1024)`... so either they've documented it strangely or the `COMPRESSED` row format stores the length out-of-band along with another block of metadata, so it doesn't count in the total bytes in this format.

`COMPRESSED` doesn't truncate the index into a prefix index and throw a warning until you go to `VARCHAR(1025)`.

    +-------+------+----------------------------------------------------------+
    | Level | Code | Message                                                  |
    +-------+------+----------------------------------------------------------+
    | Error | 1071 | Specified key was too long; max key length is 3072 bytes |
    +-------+------+----------------------------------------------------------+

It's nice the way it throws a warning instead of throwing an error, but that doesn't help us here because this still requires the explicit `ROW_FORMAT` declaration to trigger this behavior.

So, <b>my initial answer is still wrong</b>, because you have to explicitly add `ROW_FORMAT=COMPRESSED` to the end of the table definition.  Otherwise you still get the same old error.

Actually, you get two different errors in 5.6.10.  If you try to create a table with a fully-indexed `VARCHAR(1024)` you get this:

    ERROR 1709 (HY000): Index column size too large. The maximum column size is 767 bytes.

...but if you try with a fully-indexed `VARCHAR(1025)` you get this:

    ERROR 1071 (42000): Specified key was too long; max key length is 3072 bytes

That's sloppy code but the bottom line is that my answer doesn't actually fix this problem.

I don't see a way to use `ROW_FORMAT=COMPRESSED` by default, nor does it seem like a good idea if it were possible, and I'm inclined to suggest that the answer is...

...there's not a readily available workaround here.  My other thought was "character sets" but the difference between `latin1` and `utf8` still isn't sufficient to explain 1,024 vs 1000 or 767.  I'll happily get behind a better idea but at the moment, I can't think of a version of MySQL Server that this code would work properly on.


  [1]: https://dba.stackexchange.com/users/993/ypercube
  [2]: http://dev.mysql.com/doc/refman/5.6/en/innodb-other-changes-file-formats.html