Eu acho que o maior problema seria o innodb ser transacional. Você quer saber se as bibliotecas MySQL que estão sendo usadas pelos seus aplicativos auto_commit por padrão ou não.
Python , por exemplo, não é confirmado automaticamente. Isso significa que, se um aplicativo estiver inserindo uma linha imediatamente antes de fechar sua conexão, essa inserção será revertida após a alteração para innodb. O script python, por exemplo, precisa ter certeza de chamar connection.commit ();
Outro ponto de diferença pode estar relacionado às inserções ou atualizações de várias linhas. Considere uma única inserção de várias linhas
insert into tbl values (...row1...), (...row2...), (...rowN....);
Considere o que acontece se houver algum tipo de erro, como uma colisão de chave exclusiva na linha3. Com o MyISAM, as duas primeiras linhas teriam sido escritas; no innodb, todas as linhas que estavam sendo gravadas seriam revertidas, deixando nada escrito até mesmo com esse erro.
Com o innodb, você entrará no mundo dos impasses. Eles não são inerentemente ruins, a menos que ocorram com tanta frequência para impedir que qualquer trabalho seja realizado. No entanto, seus aplicativos precisarão ser codificados de forma a antecipar conflitos e manipulá-los adequadamente (o que provavelmente significa apenas tentar novamente).
Considere as limitações de memória / armazenamento. O Innodb consome muito mais recursos do que o MyISAM. Se você tem RAM suficiente para manter seus buffer pools grandes o suficiente para acomodar todas as suas tabelas, então você está dourado.
Procure tabelas que tenham grandes chaves primárias. A indexação em cluster do Innodb significa que cada índice secundário mantém outra cópia da PK da linha correspondente. Se você tiver 2 índices secundários, isso significa que cada linha PK é armazenada 3 vezes (PK + cada índice). Se o pk se estender por vários tipos de dados de colunas e grandes (char (N) por exemplo), você poderá ver como os requisitos de índice podem explodir rapidamente no innodb.