La façon de régler InnoDB est centrée sur
- InnoDB Buffer Pool: il met en cache les pages de données et les pages d'index. La quantité de données et d'index que vous pouvez mettre en cache n'est pas fonction des contraintes d'espace disque mais de la mémoire disponible et de l'espace disque actuellement utilisés par InnoDB.
- InnoDB MetaData: Par défaut, le fichier ibdata1 héberge normalement tout et tout InnoDB. Cela comprendrait les pages de données, les pages d'index, les métadonnées de table, les données MVCC .
Voici une formule que j'ai utilisée au cours des 5 dernières années pour calculer le pool de tampons InnoDB en fonction de l'espace disque utilisé par les pages de données et d'index InnoDB :
SELECT CONCAT(ROUND(KBS/POWER(1024,IF(Power1024<0,0,
IF(Power1024>3,0,Power1024)))+0.49999),SUBSTR(' KMG',IF(Power1024<0,0,
IF(Power1024>3,0,Power1024))+1,1)) recommended_innodb_buffer_pool_size
FROM (SELECT SUM(data_length+index_length) KBS FROM information_schema.tables
WHERE engine='InnoDB') A,(SELECT 2 Power1024) B;
- Utiliser (SELECT 0 Power1024) pour les octets
- Utiliser (SELECT 1 Power1024) pour KB
- Utiliser (SELECT 2 Power1024) pour MB
- Utiliser (SELECT 3 Power1024) pour GB
- Utilisez (SELECT 4 Power1024) pour TB (Envoyez-moi un e-mail si vous avez des TerraBytes de RAM)
Bien sûr, j'ai dit une fonction de la mémoire disponible et de l'espace disque actuellement utilisé par InnoDB. À partir d'ici, utilisez simplement le bon sens. LE NOMBRE RECOMMANDÉ DE LA REQUÊTE CI-DESSUS NE DEVRAIT PAS DÉPASSER 75% DE LA RAM INSTALLÉE !!! C'est la règle empirique la plus simple pour dimensionner le pool de tampons InnoDB.
Vous devez également définir innodb_flush_method sur O_DIRECT car il fournira des écritures synchrones stables d'InnoDB. J'ai également écrit un article sur la façon d'optimiser le stockage sur disque pour InnoDB .
En ce qui concerne le message, la table ne prend pas en charge l'optimisation, en recréant + analysant à la place , la raison pour laquelle vous obtenez ce message d'erreur est le fait que le moteur de stockage est InnoDB. Mécaniquement, OPTIMIZE TABLE copie simplement la table dans une table temporaire et exécute ANALYZE TABLE .
En réalité, ANALYZE TABLE contre InnoDB est complètement inutile. Même si vous avez exécuté ANALYZE TABLE sur une table InnoDB, le moteur de stockage InnoDB effectue des plongées dans l'index pour les approximations de cardinalité maintes et maintes fois, détruisant ainsi les statistiques que vous venez de compiler. En fait, Percona a effectué des tests sur ANALYZE TABLE et est également arrivé à cette même conclusion .
Voici d'autres articles que j'ai publiés au cours de l'année sur InnoDB Tuning