J'imagine la situation dans laquelle tu te retrouves.
A toi de voir, si la charge de travail sur le serveur ne doit pas augmenter et que ça "passe" en augmentant un peu la RAM alors oui, en optimisant un peu à gauche à droite, ça peut le faire.

Maintenant si une armée de commerciaux va dans les 12 mois à venir, multiplier par deux le nombres de clients, alors là, le "ça passe tout juste", risque de se transformer en "ça se crash en toute beauté"
Si tu n'es pas à l'origine du problème, il vaut peut-être mieux faire par de tes inquiétudes aux décideurs maintenant que de devoir leur expliquer en pleine saison pourquoi tout est à Hs depuis 3 jours, et pourquoi les clients de l'application hurlent.
Quitte à faire appel à un expert extérieur en design de base de donnée, qui lui pourra se permettre de partler "vrai" aux décideurs sans avoir à craindre de retour de manivelles.

Modifier une grosse base de donnée complexe, est en effet un gros boulot, compliqué et tout et tout, mais ce n'est pas non plus mission impossible.
J'ai travaillé dans une équipe qui préparait la migration d'une grosse base de donnée (3 bases de données, utilisant des technologies différentes, plusieurs centaines de tables) et ça demande avant tout une excellente planification, pour pouvoir travailler par "phases" sans arrêter du tout l'application.

Maintenant, tu ne peux vraiement pas nous poster un extrait de la structure générale de la base de donnée, histoire qu'on ai une vague idée ??