forcer type='MyISAM' sur les tables MySQL #2727

Closed
opened 11 years ago by denisb · 9 comments
denisb commented 11 years ago
Owner

spip3 et supérieur

à la création d'une nouvelle base MySQL, base et tables utilisent le moteur InnoDB ;

à la mise à jour d'une base MySQL, les 4 tables de svp (spip_depots, spip_depots_plugins, spip_paquets et spip_plugins) ainsi que spip_test sont créées avec le type InnoDB ; les autres tables et la base elle-même restant en MyISAM ;

ce, depuis MySQL v4.0 qui active InnoDB par défaut.

outre le fait qu'en InnoDB la page de réparation de la base (/ecrire/?exec=base_repair) affiche une litanie de messages d'alertes, ne serait-il pas de bon ton de forcer le retour à l'utilisation du moteur MyISAM ?

pour rappel :

  • InnoDB ne permet pas les index fulltext
  • InnoDB parait beaucoup plus lent (sur SELECT, INSERT, traitement des index secondaires) et plus gourmand en ressources mémoire et en espace disque que MyISAM
  • spip n'utilise aucun des avantages offerts par InnoDB (transactions)
spip3 et supérieur à la _création_ d'une nouvelle base MySQL, base et tables utilisent le moteur InnoDB ; à la _mise à jour_ d'une base MySQL, les 4 tables de svp (spip_depots, spip_depots_plugins, spip_paquets et spip_plugins) ainsi que spip_test sont créées avec le type InnoDB ; les autres tables et la base elle-même restant en MyISAM ; ce, depuis MySQL v4.0 qui active InnoDB par défaut. outre le fait qu'en InnoDB la page de réparation de la base (/ecrire/?exec=base_repair) affiche une litanie de messages d'alertes, ne serait-il pas de bon ton de forcer le retour à l'utilisation du moteur MyISAM ? pour rappel : * InnoDB ne permet pas les index fulltext * InnoDB parait beaucoup plus lent (sur SELECT, INSERT, traitement des index secondaires) et plus gourmand en ressources mémoire et en espace disque que MyISAM * spip n'utilise aucun des avantages offerts par InnoDB (transactions)
Owner

Je plussoie pour un retour à l'utilisation de MyISAM à la vue des restrictions imposées par InnoDB :

http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html

En ce moment je développe un plugin qui utilise les fonctions spatiales de MySQL et il m'est impossible d'activer un index sur un champ spatial à cause d'InnoDB. La création de champs de type GEOMETRY est disponible uniquement à partir de la version 5.1.

Je plussoie pour un retour à l'utilisation de MyISAM à la vue des restrictions imposées par InnoDB : http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html En ce moment je développe un plugin qui utilise les fonctions spatiales de MySQL et il m'est impossible d'activer un index sur un champ spatial à cause d'InnoDB. La création de champs de type GEOMETRY est disponible uniquement à partir de la version 5.1.
Owner

Pas mal d'infos intéressantes sur le passage de MyISAM vers InnoDB ici :

http://mysql.rjweb.org/doc.php/myisam2innodb

Pas mal d'infos intéressantes sur le passage de MyISAM vers InnoDB ici : http://mysql.rjweb.org/doc.php/myisam2innodb

Bonjour,

en fait, il existe plusieurs possibilités en fonction de ses droits, en attendant que l'option "Choix du moteur" soit introduite dans SPIP :

  • changer le default-storage-engine du my.ini ou my.cnf ou lancer mysql avec l'option --defaut-storage-engine ;
  • faire un ALTER TABLE x ENGINE = MYISAM ;
  • ajouter spip_mysql_query("SET storage_engine=MYISAM"); après le `spip_connect_db du fichier config/connect.php.

Personnellement, je pense que l'ajout d'un define('_MYSQL_STORAGE_ENGINE','MYSISAM'); dans le fichier mes_options, pour être traité facilement dans req_mysql_dist.

http://dev.mysql.com/doc/refman/5.1/en/storage-engine-setting.html

Bonjour, en fait, il existe plusieurs possibilités en fonction de ses droits, en attendant que l'option "Choix du moteur" soit introduite dans SPIP : - changer le default-storage-engine du my.ini ou my.cnf ou lancer mysql avec l'option --defaut-storage-engine ; - faire un ALTER TABLE x ENGINE = MYISAM ; - ajouter spip_mysql_query("SET storage_engine=MYISAM"); après le `spip_connect_db du fichier config/connect.php. Personnellement, je pense que l'ajout d'un define('_MYSQL_STORAGE_ENGINE','MYSISAM'); dans le fichier mes_options, pour être traité facilement dans req_mysql_dist. http://dev.mysql.com/doc/refman/5.1/en/storage-engine-setting.html
Owner
There is no content yet.
Owner

Alors du coup, ça rend les dump actuellement très problématique : dès qu'un index fulltext est présent dans une base, cett table ne se restaure pas (sur un site tout neuf) en SPIP 3.0.11. Cela indique «The used table type doesn't support FULLTEXT indexes». Effectivement toutes les tables recrées passent au format innoDb même si les tables d'origine de la sauvegarde étaient en myisam.

Alors du coup, ça rend les dump actuellement très problématique : dès qu'un index fulltext est présent dans une base, cett table ne se restaure pas (sur un site tout neuf) en SPIP 3.0.11. Cela indique «The used table type doesn't support FULLTEXT indexes». Effectivement toutes les tables recrées passent au format innoDb même si les tables d'origine de la sauvegarde étaient en myisam.
Owner

Assigné à cedric

**Assigné à cedric**
Owner

Appliqué par commit r21697.
Statut changé à Fermé

Appliqué par commit r21697. **Statut changé à Fermé**
b_b commented 8 years ago
Owner

Super, encore merci grand :)

Super, encore merci grand :)
C'est parfois (devenu)? problématique : - https://discuter.spip.net/t/alwaysdata-installation-de-spip-4/158032 - https://git.spip.net/spip/spip/issues/4277 - https://git.spip.net/spip/spip/pulls/29
Sign in to join this conversation.
No Milestone
No project
No Assignees
6 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.