De acordo com a especificação de DNS o comprimento máximo do nome de domínio é:

255 * 3 =765 <767 (apenas um pouco :-))

No entanto, observe que cada componente pode ter apenas 63 caracteres.

Então, sugiro cortar o URL nos bits do componente.

Usando http://foo. example.com/a/really/long/path?with=lots&of=query¶meters=that&goes=on&forever&and=ever

Provavelmente isso seria adequado:

• sinalizador de protocolo ["http" -> 0 ] ( armazene "http" como 0, "https" como 1 etc. )
• subdomínio ["foo" ] ( 255 - 63 =192 caracteres :eu poderia subtrair mais 2 porque min tld é 2 caracteres )
• domínio ["exemplo"], (63 caracteres)
• tld ["com"] (4 caracteres para lidar com "info" tld)
• caminho [ "a/realmente/longo/caminho"] ( contanto que você queira -armazene em uma tabela separada )
• queryparameters ["with=lots&of=query¶meters=that&goes=on&forever&and=ever" ] ( armazenar em uma tabela de chave/valor separada )
• portnumber / itens de autenticação que raramente são usados ​​podem estar em uma tabela de chave separada, se realmente necessário.

Isso lhe dá algumas vantagens interessantes:

• O índice está apenas nas partes do URL que você precisa pesquisar (índice menor!)
• as consultas podem ser limitadas às várias partes do URL (encontre todos os URLs no domínio do Facebook, por exemplo)
• qualquer URL que tenha um subdomínio/domínio muito longo é falso
• fácil de descartar parâmetros de consulta.
• pesquisa fácil de nomes de domínio/tlds que não diferencia maiúsculas de minúsculas
• descarte o açúcar de sintaxe ( "://" após o protocolo, "." entre subdomínio/domínio, domínio/tld, "/" entre tld e caminho, "?" antes da consulta, "&" "=" no consulta)
• Evita o grande problema de tabela esparsa. A maioria das urls não terá parâmetros de consulta, nem caminhos longos. Se esses campos estiverem em uma tabela separada, sua tabela principal não terá o tamanho atingido. Ao fazer consultas, mais registros caberão na memória, portanto, desempenho de consulta mais rápido.
• (mais vantagens aqui).