Guide pratique pour les administrateurs 시스템positories qui souhaitent améliorer les performances de leur instance Dolibarr tout en préservant la continuité de leurs données.
1. Pourquoi optimiser MySQL/MariaDB avec Dolibarr ?
Dolibarr est une solution ERP/CRM légère écrite en PHP. Elle repose sur un schéma de base de données simple mais, avec le temps (clients, factures, stocks, mouvements …), les tables peuvent devenir lourdes :
- Recherches fréquentes (listes de produits, clients, factures) génèrent des
SELECTcomplexes avec de nombreuxJOIN. - Mises à jour (paiements, stocks) impliquent de nombreux
UPDATEetINSERT. - Rapports et exports créent des
SELECT … GROUP BYcostauds.
Une mauvaise configuration MySQL/MariaDB entraîne :
- Des temps de réponse de plusieurs secondes voire minutes.
- Des verrous bloquants qui ralentissent les écritures simultanées.
- Un risque de corruption si le serveur n’est pas correctement sauvegardé.
L’optimisation consiste donc à :
- Adapter le serveur (variables d’
innodb,myisam, cache, etc.) à la charge attendue. - Tuner les index et les requêtes utilisées par Dolibarr.
- Vérifier la compatibilité de la version de MySQL/MariaDB avec la version de Dolibarr que vous comptez installer.
2. Pré‑requis avant toute mise à jour ou optimisation | Action | Détails | Pourquoi |
|——-|———-|———-|
| Sauvegarde complète | mysqldump -u root -p --single-transaction --quick dolibarr > dolibarr.sql | Garantit la possibilité de revenir en arrière. |
| Dump des fichiers de configuration | cp /var/www/dolibarr/conf/*.php /var/www/dolibarr/conf/*.conf . | Permet de restaurer la configuration Apache/Nginx ou les overrides. |
| Export du répertoire www | tar -czf dolibarr-backup.tar.gz /var/www/dolibarr | Utile si vous avez ajouté des plugins ou des fichiers personnalisés. |
| Test dans un environnement clone | Créez une VM ou un conteneur Docker avec la même version de MySQL et de PHP. | Vous pouvez tester l’optimisation sans toucher au serveur de production. |
| Vérifier les dépendances | php -m | grep mysqli ; php -r 'echo PHP_VERSION;' ; | Dolibarr requiert PHP >= 7.4 (ou version selon la branche). |
Astuce : Si vous utilisez un conteneur Docker, vous pouvez cloner l’image Docker (
docker run --name dolibarr-test -p 8080:80 …) et y monter le dump SQL précédemment exporté.
3. Compatibilité MySQL ↔ MariaDB avec Dolibarr
| Dolibarr version | MySQL / MariaDB min. supportées |
|---|---|
| 20.x (actuelle) | MySQL 5.7 ou MariaDB 10.2 + |
| 21.x (future) | MySQL 8.0 ou MariaDB 10.4 + |
- Pas de changement de version majeure (ex. passer de MySQL 5.7 à 8.0) sans vérifier les notes de migration de Dolibarr.
- MariaDB étant l’alternative « drop‑in » de MySQL, la plupart des optimisations sont identiques.
- Évitez les versions end‑of‑life (EOL) du SGBD (ex. MySQL 5.6) qui ne reçoivent plus de correctifs de sécurité.
4. Étapes d’optimisation MySQL/MariaDB sans casser l’existant
4.1. Analyse de la charge actuelle
-- 1. Temps de réponse moyen des requêtes DolibarrSELECT
IDX_NAME, COUNT(*) AS nb_exec,
SUM_TIMER_WAIT/1000000 AS total_sec,
ROUND(SUM_TIMER_WAIT/1000000/COUNT(*), 2) AS avg_ms
FROM performance_schema.events_statements_summary_by_digest
WHERE SCHEMA_NAME = 'dolibarr'
GROUP BY IDX_NAME
ORDER BY total_sec DESC
LIMIT 20;- Identifiez les requêtes les plus lentes. – Repérez les colonnes manquantes d’index.
4.2. Création d’index adaptés
Dolibarr ne crée pas toujours les index les plus pertinents lorsqu’on utilise des tables personnalisées (ex. tables de paiement, de mouvements de stock). Les index les plus critiques :
| Table | Colonnes à indexer | Raison |
|---|---|---|
llx_facture |
(fk_soc_id, date), (num, date) |
Filtrage fréquent par société et date. |
llx_product |
(ref, category, active) |
Recherche par référence ou catégorie dans les listes. |
llx_stock_movement |
(fk_product, date, type_movement) |
Jointures multiples dans le stock. |
llx_user |
(login, active) |
Authentification et filtres d’utilisateurs actifs. |
Après ajout d’un index :
ALTER TABLE llx_facture ADD INDEX idx_facture_soc_date (fk_soc_id, date);Bon à savoir : Sur de grosses tables (
> 1 M d’enregistrements), créez l’index hors ligne si vous êtes sur MySQL 8.0+ ou MariaDB 10.5+ (ALTER TABLE … ADD INDEX … ALGORITHM=INPLACE, LOCK=NONE;).
4.3. Tuning du serveur (variables my.cnf/mysqld.cnf)
Attention : Ne changez que une variable à la fois, puis mesurez l’impact.
| Variable | Valeur conseillée (exemple) | Impact |
|---|---|---|
innodb_buffer_pool_size |
50‑70 % de la RAM disponible si InnoDB représente la totalité des tables. | Cache des pages de données et index. |
innodb_log_file_size |
1 GB (ou plus) si vous avez de gros volumes d’écritures (paiements, stocks). | Réduit les fsync fréquents. |
innodb_log_buffer_size |
64 MB – 256 MB | Stocke temporairement les transactions avant écriture sur disque. |
max_connections |
150‑250 (selon le nombre d’utilisateurs simultanés). | Permet plus de connexions simultanées. |
table_open_cache |
2000‑4000 (si vous avez > 200 tables). | Cache des descripteurs de tables. |
query_cache_type et query_cache_size |
Désactivés (MySQL 8.0+ le désactive par défaut). | Le query cache est obsolète et peu performant. |
tmp_table_size / max_heap_table_size |
64 MB – 128 MB | Influence la création de tables temporaires pour les GROUP BY. |
open_files_limit |
65535 | Permet de gérer de nombreux fichiers ouverts (connexions, logs). |
Exemple de snippet mysqld.cnf « `ini
[mysqld]
innodb_file_per_table = 1
innodb_buffer_pool_size = 2G # à adapter RAM × 0.6
innodb_log_file_size = 1G
innodb_log_buffer_size = 128M
innodb_flush_method = O_DIRECT
max_connections = 200
table_open_cache = 4000
tmp_table_size = 64M
max_heap_table_size = 64M
union_cache_size = 4096
Après modification, **rechargez** le serveur : `systemctl restart mariadb` ou `service mysql restart`.
### 4.4. Mise à jour de Dolibarr en douceur
1. **Lisez les notes de migration** de la version cible (ex. 20.0.3 → 20.0.4).
2. **Copiez seulement le répertoire `htdocs/dolibarr`**, ne touchez pas aux fichiers de configuration (`conf/`).
3. **Exécutez les scripts de mise à jour** :
```bash
php -f /var/www/dolibarr/upgrade.php(ou php -f inc/bin/upgrade.php selon le répertoire).
- Ce script ajoute les nouvelles colonnes/indices uniquement si elles n’existent pas.
- Contrôlez les.error_log du serveur web et
mysqld.log. - Test fonctionnel : créez/éditez un client, générez une facture, validez un paiement.
- Contrôlez les.error_log du serveur web et
Rollback rapide : Si la mise à jour échoue après la migration de la base, restaurez le dump SQL précédent et réimportez‑le :
mysql -u root -p dolibarr < dolibarr.sql.
4.5. Vérifications post‑optimisation
| Check | Commande ou Requête | Critère de succès |
|---|---|---|
| Temps de réponse des listes de produits | SELECT COUNT(*) FROM llx_product; |
< 0,5 s sur le serveur de test. |
| Utilisation du buffer pool | SHOW ENGINE INNODB STATUS; → Buffer pool size vs Data used. |
Ratio ≥ 85 % d’utilisation du pool. |
| Connexions simultanées max | SELECT MAX(pthreads_connected) FROM information_schema.processlist; |
< max_connections (pas de dépassement). |
| Optimisation des index | EXPLAIN SELECT * FROM llx_facture WHERE fk_soc_id=123; |
type = ref ou range, pas ALL. |
| Erreurs MySQL | tail -f /var/log/mysql/error.log |
Aucun Deadlock ou Lock wait timeout persistant. |
5. Bonnes pratiques pour éviter de casser l’existant
| Pratique | Description | Exemple d’application |
|---|---|---|
| Toujours travailler sur une copie | Clonez la base (CREATE DATABASE dolibarr_test; SOURCE dolibarr.sql;) avant toute modification. |
Avant d’ajouter un index, créez‑le d’abord sur la copie. |
| Utiliser les transactions | Enveloppez les modifications lourdes (ALTER TABLE …) dans une transaction. |
START TRANSACTION; ALTER TABLE …; COMMIT; |
| Planifier le downtime | Effectuez l’opération pendant une période de faible trafic (ex. 02:00–04:00). | Mettre le site en « maintenance » avec un fichier maintenance.html pendant la migration. |
| Documenter chaque étape | Notez la version MySQL, la version de Dolibarr, les paramètres modifiés. | cat /etc/mysql/mariadb.cnf >> ~/optimisation_log.txt |
| Tester les plugins | Certains plugins ajoutent leurs propres tables ou déclencheurs. | Vérifiez après chaque mise à jour que les modules de paiement fonctionnent. |
6. Checklist finale avant de passer en production
| ✅ | Action |
|---|---|
| 1 | Sauvegarde complète (mysqldump, tar) + vérification de l’intégrité (gzip -t). |
| 2 | Clonage du serveur de prod → environnement de test. |
| 3 | Analyse des requêtes lentes → création des index critiques (EXPLAIN). |
| 4 | Ajustement des variables innodb_* et max_connections dans my.cnf. |
| 5 | Redémarrage MySQL et test des temps de réponse. |
| 6 | Mise à jour de Dolibarr (ou installation d’une version cible) avec exécution du script d’upgrade. |
| 7 | Vérification de la cohérence des données (SELECT COUNT(*) FROM llx_…). |
| 8 | Tests fonctionnels : création de devis, factures, gestion des stocks, paiements. |
| 9 | Contrôle des logs (/var/log/mysql/*, /var/log/apache2/*) pour détecter des erreurs. |
| 10 | Passage en production avec bascule du DNS ou du reverse‑proxy, suivi du monitoring (Grafana/Prometheus ou Zabbix). |
7. Ressources complémentaires
| Sujet | Lien (officiel) |
|---|---|
| Documentation Dolibarr – Upgrade | https://www.dolibarr.org/doc/en/upgrading/ |
| MySQL 8.0 Performance Tuning | https://dev.mysql.com/doc/refman/8.0/en/optimization.html |
| MariaDB Performance Guide | https://mariadb.com/kb/en/optimizing-mariadb-configuration/ |
| Index Advisor (Percona Toolkit) | https://www.percona.com/doc/percona-toolkit/2.2/tk-index-advisor.html |
| Benchmark Dolibarr sur MySQL | https://github.com/Dolibarr/dolibarr/wiki/Performance |
8. Exemple complet d’un script d’optimisation (shell)
#!/bin/bash
# --------------------------------------------------------------
# Script d'optimisation MySQL/MariaDB pour Dolibarr
# --------------------------------------------------------------
DB_NAME="dolibarr"
BACKUP_DIR="/backup/dolibarr_$(date +%F_%H%M)"
MYSQL_CONF="/etc/mysql/mariadb.conf.d/50-server.cnf"
# 1️⃣ Création du répertoire de sauvegarde
mkdir -p "$BACKUP_DIR"
mysqldump -u root -p"$MYSQL_ROOT_PASSWORD" "$DB_NAME" > "$BACKUP_DIR/dolibarr.sql"
tar -czf "$BACKUP_DIR/dolibarr_htdocs.tar.gz" /var/www/dolibarr
# 2️⃣ Ajout d'index critiques (hors ligne si possible)
mysql -u root -p"$MYSQL_ROOT_PASSWORD" <<SQL
USE \`$DB_NAME\`;
ALTER TABLE llx_facture ADD INDEX idx_facture_soc_date (fk_soc_id, date) ALGORITHM=INPLACE, LOCK=NONE;
ALTER TABLE llx_product ADD INDEX idx_product_ref_category (ref, category) ALGORITHM=INPLACE, LOCK=NONE;
SQL
# 3️⃣ Modification du fichier de config (backup avant)
cp "$MYSQL_CONF" "${MYSQL_CONF}.bak_$(date +%s)"
sed -i 's/^#innodb_buffer_pool_size.*/innodb_buffer_pool_size = 2G/' "$MYSQL_CONF"
sed -i 's/^#max_connections.*/max_connections = 250/' "$MYSQL_CONF"
# 4️⃣ Redémarrage du service (à faire hors heures de pic)
systemctl restart mariadb
# 5️⃣ Vérification rapide
echo "=== Vérification de la taille du buffer pool ==="
mysql -u root -p"$MYSQL_ROOT_PASSWORD" -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"
echo "✅ Optimisation terminée. Secours disponible dans $BACKUP_DIR"Important : Adaptez les noms de tables et les paramètres à votre environnement. Testez d’abord sur une instance de test.
9. Conclusion
Optimiser MySQL/MariaDB lorsqu’on utilise Dolibarr ne consiste pas à « tirer le maximum » d’un serveur à tout prix, mais à trouver le juste équilibre entre :
- Performance (temps de réponse, débit)
- Fiabilité (pas de corruptions, rollback facile)
- Compatibilité (versions de MySQL/MariaDB et de Dolibarr)
En suivant le processus décrit ci‑dessus :
- Sauvegarder et cloner votre environnement.
- Analyser les requêtes lentes et créer les index nécessaires.
- Ajuster les paramètres clés du moteur (
innodb_buffer_pool_size,max_connections, etc.). - Mettre à jour Dolibarr en veillant à ce que les scripts d’upgrade ne touchent que les objets inexistants.
- Valider chaque changement avec des tests fonctionnels et des métriques.
Vous disposerez alors d’un serveur Dolibarr réactif, stable et prêt à supporter la croissance de vos données sans risquer de casser l’existant. Bonne optimisation ! 🚀