Por dios Skeletron un VARCHAR de longitud 300 como Primary Key    intenta no hacer esto. Ten siempre pendiente recordar que los campos que vas a definir como PK que sean de longitud constantes o fijas (char, int, tinyint, smallint, etc) Y no de longitud variable (varchar) los datos de longitus variable suelen desfragmentarse mucho... no lo uses como indices.


CRC64 hasta lo que yo se, No existe en MySQL como funcion. La funcion Matematica CRC32 retorna valores unicos que no sobrepasan las 11 cifras por mas larga que sea la entrada que estas convirtiendo con CRC32 Por este lado Skeletrun confia.

Yo particularmente no recomendaria ni MD5 ni SHA1 para indice, la razon ademas de que retorna un tamano en bits mayor (algo que quiere evitarse Skeletrum) no son datos numericos sino alfanumericos... por lo cual sabes que en lenguaje de computador es mucho mas rapido la lectura de datos numericos que alfanumericos ya que los alfanumericos deben traducirse primero a numericos (aunque sea en fraciones de milisegundos pero segun lo hace) para poder interpretarlos. Entonces considerando lo anterior, CRC32 es mejor porque ahorra bityes de espacio, son caracteres siempre numericos y no sobrepasan las 11 cifras. (Hasta la fecha No he visto colisiones usando esta funcion la CRC32 en millones de datos, para mi hay una alta posibilidad que funcione acorde a lo que he visto... pero, no podria descartar que a lo mejor colisione alguna vez pero particularmente en millones de datos yo no lo he visto aun).

Que conste que la idea de insertar campos indices con la funcion CRC32 la obtuve de un ejemplo del libro 'High MySQL Optimization' escrito por la gente de Percona, esa misma gente que mencionas Vertex en los links que refieres... esa sugerencia la obtuve de ellos y hasta la fecha a mis amistades developers webs le ha servido enormemente. 

Y entonces que me dicen?
Habrá algun hash que disminuya la cantidad de coliciones?

Es mala la idea de un MD5 en un CHAR(32)??

Gracias por los comentarios Tifa..

Cuando me referia a IMAGENES, queria decir: LINKS, ya que esos links que hay en la base de datos, son links a imagenes.

Me gusta que quede claro, que no hay problemas en cuando a la velocidad de la base de datos si utilizo MD5, ya que los "SELECTS" que haré, seran con un WHERE hash1=xxxx.. o sea, los selects tendran en su "WHERE" a valores de la columna HASH1 HASH2 y HASH2, y no la columna de CODIGO (donde estaria guardado el MD5)


Ahora tambien, estaba mirando, y creo que tambien tendre que implementar el sistema que VERTEX presenta, el de 2 tablas..
Tabla 1:
[1]google[2]

Donde en tabla 2 esta:
[1] = www.
[2] = .com

Porque, analizando recien, tengo muchas, pero muchas palabras que siempre aparecen en los links, como por ejemplo:
link = link.Replace("upload.wikimedia.org/", "^")
            link = link.Replace("wikipedia", "`")
            link = link.Replace("img", "~")
            link = link.Replace("fotolog", "¢")
            link = link.Replace("metroflog", "£")
            link = link.Replace("image", "Æ")
            link = link.Replace("photo", "Ø")
            link = link.Replace("picture", "Þ")
            link = link.Replace("static.flickr.com/", "ß")

            link = link.Replace("www.", "¢")
            link = link.Replace(".com", "£")
            link = link.Replace(".org", "¤")
            link = link.Replace(".net", "¥")
            link = link.Replace(".html", "¦")
            link = link.Replace(".htm", "§")
            link = link.Replace(".php", "©")
            link = link.Replace(".png", "®")
            link = link.Replace(".jpg", "±")
            link = link.Replace(".gif", "µ")
            link = link.Replace(".jpeg", "¶")
            link = link.Replace(".index", "¼")
            link = link.Replace(".asp", "½")
            link = link.Replace(".aspx", "¾")
            link = link.Replace(".bmp", "ð")

Y como verán, aun quedan muchos opr agregar, como por ejemplo: photoS, tumbalins, y demas palabras que siempre aparecen en los links de imagenes.

Alrespecto, Tifa respondio que se comenzaria a crear un gran problemas con los "UNION" y demas.. (o me equivoco?) y es verdad...
Pregunta:
supongamos que con un select, devuelvo el LINK (campo), que tiene como HASH1(campo)=123

SELECT links FROM tablanoel WHERE hash1='123'

Una vez que tengo el link, tendré que recorrerlo buscando indices del tipo: [X]??? y realizar OTRO select por cada [X] que encuentre para reemplazar el valor?
O se podra hacer todo en una sola Consulta?

Has acertado en todo lo que dije.
Cuando hablaba de HASH, me referia a la columna, porque 3 columnas se llaman: hash1, hash2 y hash3.
bueno, a esta altura, me he quedado muy liado.

Pero he tomado una decicion:

Por ahora, reemplazare solamente los .com, .org, y esas cadenas cortitas, por simbolos extraños que se que no aparecerán en ningun link.
Luego de un tiempo, cuando vea (con algun programa que tome estadisticas de la base de datos) que hay palabras muy largas, que se repiten mucho, y que realmente vale la pena reemplazarlas por alguna otra cadena que la identifique, entonces, ahí si implementaré lo que dice Vertex.

Tendria que poner el indexador a trabajar unos cuannntoosssss dias y ver luego, cuando ya tenga muchas entradas.

Les agradezco mucho la ayuda!
Los volveré a molestar pronto..


PD.: Ya he mandado a imprimir el libro: LA BIBLIA DE MYSQL, así que espero la proxima tener menos dudas

CRC32 SI tiene colisiones