Há muitas razões para o tamanho médio da linha ser alto.

• 
  É uma aproximação. (Descobri que normalmente é 2x-3x alto.) Em um caso extremo - uma linha na tabela - ele reivindicará 16.384 bytes por linha. Esse é um bloco InnoDB. O número de linhas na tabela é estimado . O espaço em disco usado para as linhas é exato, mas veja as despesas gerais abaixo. O tamanho médio da linha é o quociente desses dois.
  
• 
  Sobrecarga por coluna -- 1 ou 2 bytes
  
• 
  Sobrecarga por linha -- 20-30 bytes -- para lidar com transações, localizar linhas em um bloco, etc.
  
• 
  Sobrecarga por bloco -- algum número de bytes por bloco de 16 KB
  
• 
  Overhead para thrashing em um BTree -- min é cerca de 1/16 de um bloco, max é cerca de metade do bloco, a média é cerca de 30% após muitas exclusões e/ou inserções aleatórias.
  
• 
  Sobrecarga para pré-alocação de pedaços de espaço em disco (1 MB? 8 MB?)
  
• 
  À medida que uma tabela cresce para caber em um bloco, o algoritmo de layout muda e a porcentagem de sobrecarga aumenta temporariamente.
  
• 
  As linhas excluídas não retornam seu espaço para o sistema operacional, portanto, o tamanho do arquivo permanece constante, aumentando assim o aparente tamanho da linha.
  
• 
  Se você não tiver uma PRIMARY KEY explícita ou um UNIQUE chave que pode ser promovida para PK, então há um campo de 6 bytes inacessíveis (por linha) para o PK.
  
• 
  TEXT grande /BLOB e até VARCHAR são armazenados "off-record". Isso complica muito os cálculos. E depende de qual dos 4 ROW_FORMATs você está usando. Em alguns casos, há um "ponteiro" de 20 bytes para cada uma dessas células.
  
• 
  FOREIGN KEY restrições não adicionam ao espaço necessário, exceto que elas podem forçar a criação de um índice.
  
• 
  INDEXes , diferente da PRIMARY KEY não estão incluídos no avg_row_length.
  
• 
  A PRIMARY KEY geralmente envolve muito pouca sobrecarga nos dados BÁrvore. Uma simples regra prática é 1% de sobrecarga (no topo da própria coluna). Essa sobrecarga são os nós não-folha do BTree.
  
• 
  Enquanto uma transação InnoDB está ocupada, quaisquer linhas modificadas são mantidas na "lista de histórico". Isso leva a mais sobrecarga.
  
• 
  (Não totalmente relacionado). COMPRESSED do InnoDB tem problemas -- ele fornece apenas cerca de 2x compactação, ao contrário da compactação de texto típica de 3x. Custa um pouco de RAM devido à necessidade de ter os dados compactados e não compactados no buffer_pool ao mesmo tempo (para pelo menos alguns blocos).
  

SHOW TABLE STATUS e buscar de information_schema.TABLES dá os mesmos dados. Existem maneiras de obter algumas insights sobre a profundidade do B+Tree para os dados e para cada tabela.