FromDual GmbH

Comment charger rapidement des données dans la base de données ?

oli.sennhauser@fromdual.com (Oli Sennhauser) — Wed, 11 Feb 2026 10:04:00 +0100

Chez notre dernier client, nous avons vraiment dû résoudre quelques questions passionnantes ! Notamment parce que la base de données n’était pas vraiment petite.

Voici quelques données clés : CPU : 2 sockets x 24 cœurs x 2 threads = 96 vCores, 756 G RAM, 2 x 10 To SSD PCIe en RAID-10 et 7 To de données, plusieurs milliers de clients, en forte croissance.

Débit actuel : 1 M SELECT/min, 56 k INSERT/min, 44 k UPDATE/min , 7 k DELETE/min en moyenne sur 30 jours. Tendance en forte hausse. Application et requêtes non optimisées de manière cohérente. Configuration de la base de données : « à la pointe de la technologie », non vérifiée par des benchmarks. Utilisation du CPU d’environ 50 % en moyenne, avec des pics supérieurs. Le système d’E/S dispose encore de capacités libres.

Le client collecte des données de position et d’autres données relatives aux appareils et les stocke dans la base de données. Il s’agit donc d’un problème IoT classique (avec séries chronologiques, table indexée en grappes, etc.).

La question qu’il a posée est la suivante : comment copier le plus rapidement possible des données d’une table (données en attente, une sorte de file d’attente) vers une autre table (données finales, par client) ?

Le flux de données se présente comme suit :

+------------+
| IoT Device |--+
+------------+ \
 \ +-----+
+------------+ \ | AS | +--------------+ Processing +------------+
| IoT Device |------+-->| |-->| Pending data |------------->| Final data |
+------------+ / | 400 | +--------------+ of data +------------+
 / +-----+
+------------+ /
| IoT Device |--+
+------------+

Trois variantes différentes pour copier les données étaient disponibles.

Variante 1: `INSERT` et `DELETE` (forme la plus simple)

La variante la plus simple est INSERT et DELETE. Cette variante est particulièrement problématique car MariaDB/MySQL et PostgreSQL ont activé AUTOCOMMIT par défaut (ici, ici, ici et ici).

Pour mieux comprendre, voici un exemple de pseudocode :

// 20k rows
for (i = 1; i <= 2000; i++) {

 SELECT * FROM pending LIMIT 10;
 foreach ( row ) {
 INSERT INTO final;
 -- implicit COMMIT
 DELETE FROM pending WHERE id = row[id];
 -- implicit COMMIT
 }
}

Si nous voulons copier 20 000 lignes, cette variante génère 40 000 COMMIT (fsync) et 42 000 allers-retours réseau !

Variante 2: `START TRANSACTION` et `INSERT` et `DELETE`

Cette variante est utilisée par les développeurs de bases de données plus expérimentés. Voici le pseudocode correspondant :

// 20k rows
for (i = 1; i <= 2000; i++) {

 SELECT * FROM pending LIMIT 10;
 START TRANSACTION;
 foreach ( row ) {
 INSERT INTO final;
 DELETE FROM pending WHERE id = row[id];
 }
 COMMIT;
}

Si nous voulons copier 20 000 lignes dans cet exemple, cette variante ne génère plus que 2 000 COMMIT (fsync) ! Soit 20 fois moins ! Mais en contrepartie, 46 000 allers-retours réseau (10 % de plus).

Variante 3: `START TRANSACTION` et `INSERT` et `DELETE` optimisés

Cette variante est un peu plus exigeante sur le plan technique. Elle est utilisée lorsque l’on souhaite se rapprocher un peu plus des limites du possible. Voici le pseudocode correspondant :

// 20k rows
for (i = 1; i <= 2000; i++) {

 SELECT * FROM pending LIMIT 10;
 START TRANSACTION;
 INSERT INTO final (), (), (), (), (), (), (), (), (), ();
 DELETE FROM pending WHERE id = IN (...);
 COMMIT;
}

Cette troisième variante ne génère également que 2 k COMMIT (fsync) pour 20 k lignes, mais évite la boucle via les instructions INSERT et DELETE dans la base de données. Nous économisons ainsi d’une part les allers-retours réseau (plus que 10 k) et les cycles CPU sur la base de données (qui sont difficilement évolutifs) pour analyser les requêtes.

Configuration du test

Pour tester le tout, nous avons préparé un petit script : load_data.php

Préparation et exécution avec MariaDB/MySQL

Vous pouvez effectuer vous-même ces tests à l’aide des commandes suivantes :

SQL> CREATE DATABASE test;
SQL> CREATE USER 'app'@'127.0.0.1' IDENTIFIED BY 'secret';
SQL> GRANT ALL ON *.* TO 'app'@'127.0.0.1';

$ ./load_data.php --database-type=mysql --database=test --host=127.0.0.1 --port=3306 --user=app --password=secret --prepare

$ for i in $(seq 5) ; do
 ./load_data.php --database-type=mysql --database=test --host=127.0.0.1 --port=3306 --user=app --password=secret --run --variant=1
 ./load_data.php --database-type=mysql --database=test --host=127.0.0.1 --port=3306 --user=app --password=secret --run --variant=2
 ./load_data.php --database-type=mysql --database=test --host=127.0.0.1 --port=3306 --user=app --password=secret --run --variant=3
done

$ ./load_data.php --database-type=mysql --database=test --host=127.0.0.1 --port=3306 --user=app --password=secret --clean-up

Chacun peut obtenir les valeurs mesurées à l’aide du script de test correspondant.

Préparation et exécution avec PostgreSQL

Vous pouvez effectuer ces tests vous-même à l’aide des commandes suivantes :

postgres# CREATE DATABASE test;
postgres# CREATE USER app PASSWORD 'secret';
postgres# GRANT ALL ON DATABASE test TO app;
postgres# GRANT ALL ON SCHEMA public TO app;

$ ./load_data.php --database-type=postgresql --database=test --host=127.0.0.1 --port=5432 --user=app --password=secret --prepare

$ for i in $(seq 5) ; do
 ./load_data.php --database-type=postgresql --database=test --host=127.0.0.1 --port=5432 --user=app --password=secret --run --variant=1
 ./load_data.php --database-type=postgresql --database=test --host=127.0.0.1 --port=5432 --user=app --password=secret --run --variant=2
 ./load_data.php --database-type=postgresql --database=test --host=127.0.0.1 --port=5432 --user=app --password=secret --run --variant=3
done

$ ./load_data.php --database-type=postgresql --database=test --host=127.0.0.1 --port=5432 --user=app --password=secret --clean-up

Chacun peut obtenir les valeurs mesurées à l’aide du script de test correspondant.

Résultats

Afin d’éviter toute discussion inutile, nous n’avons indiqué ici « que » les performances relatives (durée d’exécution), comme le fait MarkC ces derniers temps. Nos valeurs mesurées peuvent être mises à disposition de manière bilatérale. Elles peuvent toutefois être facilement reproduites à l’aide du script de test.

Moins, c’est mieux :

	Variante 1	Variante 2	Variante 3
MariaDB 11.8, avg(5)	100.0%	7.5%	6.2%
PostgreSQL 19dev, avg(5)	100.0%	11.2%	7.0%

**Attention ** : les valeurs de MariaDB/MySQL et PostgreSQL ne peuvent PAS être comparées directement !

Et voici l’évaluation graphique :

Remarques

Avec des disques plus rapides, la différence entre 1 et 2/3 n’aurait probablement pas été aussi importante. Les tests effectués chez le client n’ont montré « qu’un » facteur 5 (au lieu d’un facteur 9 à 16) de différence.

Il existe certainement d’autres possibilités pour optimiser encore ce processus de chargement. Voici celles qui me viennent à l’esprit :

INSERT INTO ... SELECT * FROM
LOAD DATA INFILE/COPY, si possible
Prepared Statements
Server side Stored Language (SQL/PSM, PL/pgSQL, …) :-(
PDO-Fetch des résultats ?
etc.

Je devrais peut-être me procurer un profileur (Xdebug ou xhprof) ?

Autres articles

Cette page a été traduite à l’aide de deepl.com.

MariaDB a détruit le concept du buffer pool configurable dynamiquement !

oli.sennhauser@fromdual.com (Oli Sennhauser) — Mon, 09 Feb 2026 19:14:00 +0100

Description du problème

MySQL a introduit le InnoDB buffer pool configurable dynamiquement dans la version 5.7.5 en septembre 2014 (ici et ici) :

The innodb_buffer_pool_size configuration option can be set dynamically using a SET statement, allowing you to resize the buffer pool without restarting the server. For example:

mysql> SET GLOBAL innodb_buffer_pool_size=402653184;

MariaDB 10.2.2 a repris cette fonctionnalité en septembre 2016 (source) :

InnoDB was merged from MySQL-5.7.14 (XtraDB is disabled in MariaDB-10.2.2 pending a similar merge)

Le problème est, d’une part, que cette fonctionnalité ne fonctionne plus comme avant et ne fonctionne plus comme prévu. D’autre part, ils ont modifié le comportement au printemps 2025 dans le cadre d’une série de versions majeures (LTS), ce qui, à mon avis, est absolument inacceptable (source) :

From MariaDB 10.11.12 / 11.4.6 / 11.8.2, there are significant changes to the InnoDB buffer pool behavior.

De plus, la description à ce sujet est assez maigre (source) :

decreasing innodb_buffer_pool_size at runtime does not release memory (MDEV-32339)

reorganise innodb buffer pool (and remove buffer pool chunks) (MDEV-29445)

The Linux memory pressure interface, which could previously not be disabled and could cause performance anomalies, was rewritten and is disabled by default. (MDEV-34863)

Server crashes when resizing default innodb buffer pool after setting innodb-buffer-pool-chunk-size to 1M (MDEV-34677)

Dans le journal de travail correspondant (MDEV-36197), MarkoM décrit également un autre comportement :

innodb_buffer_pool_size_auto_max (my proposal for this task) would set the maximum for the automation (default: 0 to disable the logic).

ce qui, à mon avis, aurait été beaucoup plus judicieux.

Comment cela fonctionnait-il auparavant ?

Comment cela fonctionnait-il auparavant avec MariaDB et comment cela fonctionne-t-il encore aujourd’hui avec MySQL :

SQL> SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool%size';
+-------------------------------+-----------+
| Variable_name | Value |
+-------------------------------+-----------+
| innodb_buffer_pool_chunk_size | 2097152 |
| innodb_buffer_pool_size | 134217728 |
+-------------------------------+-----------+

SQL> SET GLOBAL innodb_buffer_pool_size = @@innodb_buffer_pool_chunk_size * 128;

SQL> SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool%size';
+-------------------------------+-----------+
| Variable_name | Value |
+-------------------------------+-----------+
| innodb_buffer_pool_chunk_size | 2097152 |
| innodb_buffer_pool_size | 268435456 |
+-------------------------------+-----------+

Tout est donc OK. Cela fonctionne comme prévu et comme d’habitude.

Que fait MariaDB aujourd’hui ?

Que se passe-t-il aujourd’hui avec MariaDB :

SQL> SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool%size%';
+----------------------------------+-----------+
| Variable_name | Value |
+----------------------------------+-----------+
| innodb_buffer_pool_chunk_size | 0 |
| innodb_buffer_pool_size | 134217728 |
| innodb_buffer_pool_size_auto_min | 134217728 |
| innodb_buffer_pool_size_max | 134217728 |
+----------------------------------+-----------+

SQL> SET GLOBAL innodb_buffer_pool_size = 256*1024*1024;
Query OK, 0 rows affected, 1 warning (0.000 sec)

SQL> show warnings;
+---------+------+----------------------------------------------------------------+
| Level | Code | Message |
+---------+------+----------------------------------------------------------------+
| Warning | 1292 | Truncated incorrect innodb_buffer_pool_size value: '268435456' |
+---------+------+----------------------------------------------------------------+

SQL> SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool%size%';
+----------------------------------+-----------+
| Variable_name | Value |
+----------------------------------+-----------+
| innodb_buffer_pool_chunk_size | 0 |
| innodb_buffer_pool_size | 134217728 |
| innodb_buffer_pool_size_auto_min | 134217728 |
| innodb_buffer_pool_size_max | 134217728 |
+----------------------------------+-----------+

Absolument rien ! Pas même une erreur, juste un avertissement. Et si je ne regarde pas attentivement, je ne remarque même pas que quelque chose n’a pas fonctionné.

Le journal d’erreurs MariaDB indique :

[Note] InnoDB: Memory pressure event disregarded; innodb_buffer_pool_size=128m, innodb_buffer_pool_size_auto_min=128m

En cherchant un peu, on découvre que quelque chose a changé ici : Buffer Pool Changes et on essaie intuitivement :

SQL> SET GLOBAL innodb_buffer_pool_size_max = 256*1024*1024;
ERROR 1238 (HY000): Variable 'innodb_buffer_pool_size_max' is a read only variable

Mais cela ne fonctionne pas non plus.

Cela signifie qu’il faut redémarrer la base de données ! Et cela peut arriver précisément au moment où l’on n’a pas besoin de redémarrer et où l’on aurait besoin de cette fonctionnalité…

La documentation indique également (source) :

Default Value: specified by the initial value of innodb_buffer_pool_size, rounded up to the block size of that variable. See the section about buffer pool changes in MariaDB 10.11.12, 11.4.6, and 11.8.2.

et (source):

If innodb_buffer_pool_size_max is 0 or not specified, it defaults to the innodb_buffer_pool_size value.

Cela signifie que je dois à nouveau réfléchir à l’avance à la taille que je dois donner à innodb_buffer_pool_size_max et que je ne peux corriger qu’après coup, si je l’ai oublié ou si je me suis trompé dans mon estimation.

À mon avis, il s’agit d’un véritable recul d’un point de vue opérationnel. Il s’agit probablement d’une nouvelle implémentation pour certaines solutions Cloud-only as a Service (Enterprise ?).

Ma suggestion est la suivante : soit, comme proposé dans MDEV, 0 désactive cette fonctionnalité et le comportement reste inchangé, soit la valeur par défaut est fixée à 75 % de la taille de la RAM, comme le fait innodb_dedicated_server dans MySQL.

J’ai pris la liberté d’ouvrir un bug ici : New InnoDB Buffer Pool autosize feature not so optimal implemented.

FedericoR a gentiment recommandé le lien suivant : Issues with new buffer pool configuration in MariaDB Minors (10.11.12/13/14, 11.4.6/7/8, 11.8.2/3). Je ne semble pas être le seul à avoir été contrarié par ce changement…

Comment PostgreSQL procède-t-il ?

PostgreSQL n’est actuellement pas (encore) en mesure de modifier dynamiquement les shared_buffers. La valeur par défaut est généralement de 128 Mo. Ici, la règle générale, similaire à celle de MyISAM, est de 25 à 40 % de la RAM. Cependant, l’absence de cette fonctionnalité n’est probablement pas si grave dans PostgreSQL, car PostgreSQL s’appuie fortement sur le cache du système de fichiers, tout comme MyISAM.

Source: Resource Consumption

Commentaires

Voir ici.

Cette page a été traduite à l’aide de deepl.com.

Combien d'espace NULL occupe-t-il?

oli.sennhauser@fromdual.com (Oli Sennhauser) — Sun, 08 Feb 2026 16:15:00 +0100

Lors de ma dernière intervention chez le client, celui-ci est venu me voir, rayonnant de joie, pour me dire qu’il avait suivi mon conseil et changé toutes les colonnes de clé primaire de BIGINT (8 octets) à INT (4 octets), et que cela avait beaucoup apporté ! Sa base de données MySQL 8.4 avait désormais perdu 750 Go (sur 5,5 To). Super!

Et oui, je sais que cela contredit les recommandations de certains de mes collègues PostgreSQL (ici et ici). Dans le monde MySQL, on accorde plutôt de l’importance à ce genre de choses (source):

Use the most efficient (smallest) data types possible. MySQL has many specialized types that save disk space and memory. For example, use the smaller integer types if possible to get smaller tables

De plus, InnoDB fonctionne un peu différemment (table clusterée et clé primaire dans toutes les clés secondaires) de PostgreSQL (table heap, index avec pointeur de ligne (ctid)).

Mais ce n’est pas vraiment le sujet. Immédiatement après, il a demandé si la mise à NULL des colonnes de type DOUBLE (8 octets, en langage PostgreSQL DOUBLE PRECISION) permettrait également de gagner de la place ou s’il valait mieux supprimer les colonnes. Ma première réponse instinctive pour DOUBLE a été: NULL est utile, suivi de OPTIMIZE TABLE (dans le langage PostgreSQL, VACUUM FULL). Mais ma deuxième réflexion a été: DOUBLE est un type de données fixe plus long, est-ce que cela s’applique également à NULL ou seulement aux types de données de longueur variable ? La prudence est mère de sûreté ! Il faut d’abord consulter le manuel…

Et on y trouve (source):

Declare columns to be NOT NULL if possible. It makes SQL operations faster, by enabling better use of indexes and eliminating overhead for testing whether each value is NULL. You also save some storage space, one bit per column. If you really need NULL values in your tables, use them. Just avoid the default setting that allows NULL values in every column.

et (source):

The variable-length part of the record header contains a bit vector for indicating NULL columns. … Columns that are NULL do not occupy space other than the bit in this vector. The variable-length part of the header also contains the lengths of variable-length columns. Each length takes one or two bytes, depending on the maximum length of the column. If all columns in the index are NOT NULL and have a fixed length, the record header has no variable-length part.

Essai avec MariaDB/MySQL

Montage expérimental

D’une certaine manière, cela me semble un peu trop compliqué. Un petit croquis aiderait peut-être ? Faisons donc un essai:

SQL> -- DROP TABLE IF EXISTS tracking;

SQL> CREATE TABLE tracking (
 id INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT
, d0 DOUBLE, d1 DOUBLE, d2 DOUBLE, d3 DOUBLE, d4 DOUBLE
, d5 DOUBLE, d6 DOUBLE, d7 DOUBLE, d8 DOUBLE, d9 DOUBLE
);

SQL> INSERT INTO tracking SELECT NULL, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0;
SQL> INSERT INTO tracking SELECT NULL, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0 FROM tracking;
... bis 16 M rows

La table atteint une taille d’environ 1,8 Go pour 16 millions de lignes, tant dans MariaDB que dans MySQL. Comme ces informations ne sont indiquées que de manière très imprécise dans INFORMATION_SCHEMA, nous vérifions dans le système de fichiers:

MariaDB 11.8:

SQL> system ls -l tracking.ibd
-rw-rw---- 1 mysql mysql 1206 Feb 7 10:28 tracking.frm
-rw-rw---- 1 mysql mysql 1933574144 Feb 7 10:32 tracking.ibd

MySQL 8.4:

SQL> system ls -l tracking.ibd
-rw-r----- 1 mysql mysql 1929379840 Feb 7 10:33 tracking.ibd

Défragmentation du tableau

Nous « défragmentons » ensuite le tableau à l’aide de la commande OPTIMIZE TABLE:

SQL> OPTIMIZE TABLE tracking;
+---------------+----------+----------+-------------------------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+---------------+----------+----------+-------------------------------------------------------------------+
| test.tracking | optimize | note | Table does not support optimize, doing recreate + analyze instead |
| test.tracking | optimize | status | OK |
+---------------+----------+----------+-------------------------------------------------------------------+

Attention: le tableau est copié une fois ! Il faut donc temporairement doubler l’espace disque ! Nous pouvons observer cela pendant l’exécution de la commande OPTIMIZE TABLE:

MariaDB:

$ watch -d -n 1 'ls -l trac* \#*'
-rw-rw---- 1 mysql mysql 1206 Feb 7 10:39 '#sql-alter-d57-8c.frm'
-rw-rw---- 1 mysql mysql 968884224 Feb 7 10:39 '#sql-alter-d57-8c.ibd'
-rw-rw---- 1 mysql mysql 1206 Feb 7 10:28 tracking.frm
-rw-rw---- 1 mysql mysql 1933574144 Feb 7 10:32 tracking.ibd

MySQL:

$ watch -d -n 1 'ls -l trac* \#*'
-rw-r----- 1 mysql mysql 369098752 Feb 7 10:40 #sql-ib1594-4164062678.ibd
-rw-r----- 1 mysql mysql 1929379840 Feb 7 10:33 tracking.ibd

Mais le résultat est étonnant ! Avec MariaDB, la taille de la table est restée à peu près la même:

-rw-rw---- 1 mysql mysql 1206 Feb 7 10:39 tracking.frm
-rw-rw---- 1 mysql mysql 1912602624 Feb 7 10:39 tracking.ibd

Avec MySQL, en revanche, la taille de la table a même augmenté d’environ 14 % après la « défragmentation »:

-rw-r----- 1 mysql mysql 2197815296 Feb 7 10:41 tracking.ibd

Si nous exécutons à nouveau la commande OPTIMIZE TABLE, la taille reste constante tant avec MariaDB qu’avec MySQL:

MariaDB:

-rw-rw---- 1 mysql mysql 1206 Feb 7 10:46 tracking.frm
-rw-rw---- 1 mysql mysql 1912602624 Feb 7 10:48 tracking.ibd

MySQL:

-rw-r----- 1 mysql mysql 2197815296 Feb 7 10:48 tracking.ibd

Essai 1: mise à `NULL`

Nous mettons maintenant les valeurs à NULL:

SQL> UPDATE tracking
SET d0 = NULL, d1 = NULL, d2 = NULL, d3 = NULL, d4 = NULL
 , d5 = NULL, d6 = NULL, d7 = NULL, d8 = NULL, d9 = NULL
;

Après cette étape, la taille des fichiers a même légèrement augmenté:

MariaDB (+1.3%):

-rw-rw---- 1 mysql mysql 1206 Feb 7 10:49 tracking.frm
-rw-rw---- 1 mysql mysql 1937768448 Feb 7 11:04 tracking.ibd

MySQL (+0.2%):

-rw-r----- 1 mysql mysql 2202009600 Feb 7 11:04 tracking.ibd

Nous défragmentons ensuite à nouveau la table avec la commande OPTIMIZE TABLE. Comme prévu, les tables rétrécissent.

MariaDB (à 23%):

-rw-rw---- 1 mysql mysql 1206 Feb 7 11:09 tracking.frm
-rw-rw---- 1 mysql mysql 448790528 Feb 7 11:10 tracking.ibd

MySQL (à 24%):

-rw-r----- 1 mysql mysql 520093696 Feb 7 11:10 tracking.ibd

Une nouvelle commande OPTIMIZE TABLE n’apporte alors PLUS AUCUN changement dans la taille des fichiers…

Essai 2: suppression des colonnes

Nous essayons maintenant à nouveau avec la commande DROP COLUMN. La situation de départ est à nouveau la même que celle décrite ci-dessus:

MariaDB:

-rw-rw---- 1 mysql mysql 1206 Feb 7 11:15 tracking.frm
-rw-rw---- 1 mysql mysql 1933574144 Feb 7 11:18 tracking.ibd

MySQL:

-rw-r----- 1 mysql mysql 1929379840 Feb 7 11:19 tracking.ibd

Après la commande OPTIMIZE TABLE, les valeurs sont similaires à celles du premier essai:

MariaDB:

-rw-rw---- 1 mysql mysql 1206 Feb 7 11:20 tracking.frm
-rw-rw---- 1 mysql mysql 1912602624 Feb 7 11:21 tracking.ibd

MySQL:

-rw-r----- 1 mysql mysql 2197815296 Feb 7 11:21 tracking.ibd

Une nouvelle commande OPTIMIZE TABLE n’apporte également aucun changement supplémentaire, comme ci-dessus:

MariaDB:

-rw-rw---- 1 mysql mysql 1206 Feb 7 11:22 tracking.frm
-rw-rw---- 1 mysql mysql 1912602624 Feb 7 11:23 tracking.ibd

MySQL:

-rw-r----- 1 mysql mysql 2197815296 Feb 7 11:24 tracking.ibd

Et maintenant, le deuxième essai avec la suppression des colonnes:

SQL> ALTER TABLE tracking
 DROP COLUMN d0, DROP COLUMN d1, DROP COLUMN d2, DROP COLUMN d3, DROP COLUMN d4
, DROP COLUMN d5, DROP COLUMN d6, DROP COLUMN d7, DROP COLUMN d8, DROP COLUMN d9
;

Tout d’abord, nous constatons que la commande INSTANTANEOUS n’apporte aucune modification aux données, mais uniquement aux métadonnées. D’un côté, c’est une bonne chose, car l’impact sur l’application est ainsi réduit au minimum. D’un autre côté, cela signifie également qu’il n’y a pas de gain d’espace.

Nous allons donc à nouveau nous attaquer au problème avec la commande OPTIMIZE TABLE:

MariaDB (à 93%):

-rw-rw---- 1 mysql mysql 925 Feb 7 11:28 tracking.frm
-rw-rw---- 1 mysql mysql 415236096 Feb 7 11:29 tracking.ibd

MySQL (à 92%):

-rw-r----- 1 mysql mysql 478150656 Feb 7 11:28 tracking.ibd

Conclusion

La mise à NULL des colonnes et la suppression des colonnes permettent toutes deux de gagner beaucoup d’espace. La suppression des colonnes permet toutefois de gagner environ 7 % de plus que la mise à NULL. Si cela est possible au niveau de l’application, il convient donc de supprimer les colonnes qui ne sont plus nécessaires ou, si cela n’est pas possible, de les mettre à NULL.

Essai avec PostgreSQL

Voyons maintenant ce qu’il en est avec PostgreSQL 19devel.

Montage expérimental

Le montage expérimental est similaire à celui utilisé pour MariaDB/MySQL:

postgres=# -- DROP TABLE IF EXISTS tracking;

postgres=# CREATE TABLE tracking (
 id SERIAL PRIMARY KEY
, d0 DOUBLE PRECISION, d1 DOUBLE PRECISION, d2 DOUBLE PRECISION, d3 DOUBLE PRECISION, d4 DOUBLE PRECISION
, d5 DOUBLE PRECISION, d6 DOUBLE PRECISION, d7 DOUBLE PRECISION, d8 DOUBLE PRECISION, d9 DOUBLE PRECISION
);

postgres=# \timing

postgres=# INSERT INTO tracking (d0, d1, d2, d3, d4, d5, d6, d7, d8, d9)
 SELECT 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0;
postgres=# INSERT INTO tracking (d0, d1, d2, d3, d4, d5, d6, d7, d8, d9)
 SELECT 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0 FROM tracking;
... bis 16 M rows

Commençons par déterminer la taille réelle du tableau. PostgreSQL semble connaître cette information avec une grande précision:

postgres=# SELECT pg_relation_size('tracking') AS tab_siz
 , pg_size_pretty(pg_relation_size('tracking')) AS tab_siz_prtty
 , pg_indexes_size('tracking') AS idx_siz
 , pg_size_pretty(pg_indexes_size('tracking')) AS idx_siz_prtty
 , pg_relation_size('tracking') + pg_indexes_size('tracking') AS tab_and_idx_siz
 , pg_size_pretty(pg_relation_size('tracking') + pg_indexes_size('tracking')) AS tab_and_idx_siz_prtty
 , pg_total_relation_size('tracking') AS tot_rel_siz
 , pg_size_pretty(pg_total_relation_size('tracking')) AS tot_rel_siz_prtty
;
 tab_siz | tab_siz_prtty | idx_siz | idx_siz_prtty | tab_and_idx_siz | tab_and_idx_siz_prtty | tot_rel_siz | tot_rel_siz_prtty
------------+---------------+-----------+---------------+-----------------+-----------------------+-------------+-------------------
 1963417600 | 1872 MB | 376856576 | 359 MB | 2340274176 | 2232 MB | 2340798464 | 2232 MB

Ensuite, nous voulons savoir où se trouvent ces fichiers dans le système de fichiers:

postgres=# SELECT oid AS db_oid FROM pg_database WHERE datname = current_database();
 db_oid
--------
 5

postgres=# SELECT oid AS table_oid, relname, relnamespace, relfilenode
 FROM pg_class WHERE relname = 'tracking';
 table_oid | relname | relnamespace | relfilenode
-----------+----------+--------------+-------------
 40965 | tracking | 2200 | 40965

postgres=# SELECT i.indexrelid::regclass as index_name, i.indexrelid as index_oid
 FROM pg_index i
 JOIN pg_class c ON i.indrelid = c.oid
 WHERE c.relname = 'tracking';
 index_name | index_oid
---------------+-----------
 tracking_pkey | 40970

postgres=# SELECT pg_relation_filepath('tracking');
 pg_relation_filepath
----------------------
 base/5/40965

Taille des tables et des index dans le système de fichiers:

$ ls -ltr 40965* 40970*
-rw------- 1 mysql mysql 40960 Feb 7 18:33 40965_vm
-rw------- 1 mysql mysql 499712 Feb 7 18:33 40965_fsm
-rw------- 1 mysql mysql 889675776 Feb 7 18:34 40965.1
-rw------- 1 mysql mysql 1073741824 Feb 7 18:34 40965
-rw------- 1 mysql mysql 376856576 Feb 7 18:35 40970

*_fsm signifie « free space map » (carte de l’espace libre)
*_vm signifie « visibility map » (carte de visibilité)
*.1 signifie 2e segment de l’objet (table ou index)

PostgreSQL semble fonctionner par défaut avec des segments de 1 Go et, contrairement à MariaDB/MySQL (INFORMATION_SCHEMA), connaître très précisément la taille de ses fichiers. Et la différence mentionnée ci-dessus (entre tot_rel_siz et tab_and_idx_siz) s’explique par les fichiers fsm et vm.

L’équivalent PostgreSQL de la commande OPTIMIZE TABLE de MariaDB/MySQL est la commande VACUUM FULL:

postgres=# VACUUM FULL tracking;

$ ls -ltr
-rw------- 1 mysql mysql 40960 Feb 7 18:39 40965_vm
-rw------- 1 mysql mysql 499712 Feb 7 18:39 40965_fsm
-rw------- 1 mysql mysql 1073741824 Feb 7 18:39 40965
-rw------- 1 mysql mysql 889675776 Feb 7 18:39 40965.1
-rw------- 1 mysql mysql 1073741824 Feb 7 18:39 40972
-rw------- 1 mysql mysql 889675776 Feb 7 18:39 40972.1
-rw------- 1 mysql mysql 0 Feb 7 18:39 40975

...

-rw------- 1 mysql mysql 49152 Feb 7 18:39 2704
-rw------- 1 mysql mysql 32768 Feb 7 18:39 2703
-rw------- 1 mysql mysql 32768 Feb 7 18:39 2696
-rw------- 1 mysql mysql 65536 Feb 7 18:39 2674
-rw------- 1 mysql mysql 81920 Feb 7 18:39 2673
-rw------- 1 mysql mysql 98304 Feb 7 18:39 2659
-rw------- 1 mysql mysql 139264 Feb 7 18:39 2658
-rw------- 1 mysql mysql 24576 Feb 7 18:39 2619_fsm
-rw------- 1 mysql mysql 163840 Feb 7 18:39 2619
-rw------- 1 mysql mysql 106496 Feb 7 18:39 2608
-rw------- 1 mysql mysql 491520 Feb 7 18:39 1249
-rw------- 1 mysql mysql 122880 Feb 7 18:39 1247
-rw------- 1 mysql mysql 32768 Feb 7 18:39 2662
-rw------- 1 mysql mysql 114688 Feb 7 18:39 1259
-rw------- 1 mysql mysql 16384 Feb 7 18:39 3455
-rw------- 1 mysql mysql 49152 Feb 7 18:39 2663
-rw------- 1 mysql mysql 1073741824 Feb 7 18:39 40972
-rw------- 1 mysql mysql 889675776 Feb 7 18:39 40972.1
-rw------- 1 mysql mysql 376864768 Feb 7 18:39 40975
-rw------- 1 mysql mysql 0 Feb 7 18:39 40965
-rw------- 1 mysql mysql 0 Feb 7 18:39 40970

La première chose que l’on remarque, c’est que PostgreSQL génère beaucoup de fichiers et que le fichier « free space map » a disparu. Contrairement à MariaDB/MySQL, les segments de table sont restés de taille identique. On constate également que l’ancienne table a « disparu » (40965, 40970) et qu’une nouvelle a été créée (40972 et 40975). La commande VACUUM FULL de PostgreSQL crée donc également une copie des données, comme dans MariaDB/MySQL.

postgres=# SELECT pg_relation_size('tracking') AS tab_siz
 , pg_size_pretty(pg_relation_size('tracking')) AS tab_siz_prtty
 , pg_indexes_size('tracking') AS idx_siz
 , pg_size_pretty(pg_indexes_size('tracking')) AS idx_siz_prtty
 , pg_relation_size('tracking') + pg_indexes_size('tracking') AS tab_and_idx_siz
 , pg_size_pretty(pg_relation_size('tracking') + pg_indexes_size('tracking')) AS tab_and_idx_siz_prtty
 , pg_total_relation_size('tracking') AS tot_rel_siz
 , pg_size_pretty(pg_total_relation_size('tracking')) AS tot_rel_siz_prtty
;
 tab_siz | tab_siz_prtty | idx_siz | idx_siz_prtty | tab_and_idx_siz | tab_and_idx_siz_prtty | tot_rel_siz | tot_rel_siz_prtty
------------+---------------+-----------+---------------+-----------------+-----------------------+-------------+-------------------
 1963417600 | 1872 MB | 376864768 | 359 MB | 2340282368 | 2232 MB | 2340282368 | 2232 MB

Pour comprendre quels autres fichiers/objets ont été affectés, la requête suivante est utile:

postgres=# SELECT c.oid, c.relname, ns.nspname
FROM pg_class AS c
JOIN pg_namespace AS ns ON ns.oid = c.relnamespace
WHERE c.oid IN (2704, 2703, 2696, 2674, 2673, 2659, 2658, 2619, 2608, 1249, 1247, 40972, 2662, 1259, 3455, 2663, 40975, 40965, 40970)
;
 oid | relname | nspname
-------+-----------------------------------+------------
 40965 | tracking | public
 40970 | tracking_pkey | public
 2619 | pg_statistic | pg_catalog
 1247 | pg_type | pg_catalog
 2703 | pg_type_oid_index | pg_catalog
 2704 | pg_type_typname_nsp_index | pg_catalog
 2658 | pg_attribute_relid_attnam_index | pg_catalog
 2659 | pg_attribute_relid_attnum_index | pg_catalog
 2662 | pg_class_oid_index | pg_catalog
 2663 | pg_class_relname_nsp_index | pg_catalog
 3455 | pg_class_tblspc_relfilenode_index | pg_catalog
 2696 | pg_statistic_relid_att_inh_index | pg_catalog
 2673 | pg_depend_depender_index | pg_catalog
 2674 | pg_depend_reference_index | pg_catalog
 1249 | pg_attribute | pg_catalog
 1259 | pg_class | pg_catalog
 2608 | pg_depend | pg_catalog

postgres=# SELECT i.indexrelid::regclass as index_name, i.indexrelid as index_oid, ns.nspname
 FROM pg_index i
 JOIN pg_class c ON i.indrelid = c.oid
 JOIN pg_namespace AS ns ON ns.oid = c.relnamespace
 WHERE c.oid IN (2704, 2703, 2696, 2674, 2673, 2659, 2658, 2619, 2608, 1249, 1247, 40972, 2662, 1259, 3455, 2663, 40975, 40965, 40970)
;
 index_name | index_oid | nspname
-----------------------------------+-----------+------------
 pg_type_typname_nsp_index | 2704 | pg_catalog
 pg_attribute_relid_attnam_index | 2658 | pg_catalog
 tracking_pkey | 40970 | public
 pg_class_relname_nsp_index | 2663 | pg_catalog
 pg_class_tblspc_relfilenode_index | 3455 | pg_catalog
 pg_type_oid_index | 2703 | pg_catalog
 pg_attribute_relid_attnum_index | 2659 | pg_catalog
 pg_statistic_relid_att_inh_index | 2696 | pg_catalog
 pg_depend_depender_index | 2673 | pg_catalog
 pg_depend_reference_index | 2674 | pg_catalog
 pg_class_oid_index | 2662 | pg_catalog

Essai 1: mise à `NULL`

Nous mettons également à NULL les colonnes dans PostgreSQL. Nous n’avons plus besoin de consulter le système de fichiers, car PostgreSQL semble connaître précisément la taille des fichiers, comme nous l’avons vu ci-dessus:

postgres=# UPDATE tracking
SET d0 = NULL, d1 = NULL, d2 = NULL, d3 = NULL, d4 = NULL
 , d5 = NULL, d6 = NULL, d7 = NULL, d8 = NULL, d9 = NULL
;

postgres=# SELECT pg_relation_size('tracking') AS tab_siz
 , pg_size_pretty(pg_relation_size('tracking')) AS tab_siz_prtty
 , pg_indexes_size('tracking') AS idx_siz
 , pg_size_pretty(pg_indexes_size('tracking')) AS idx_siz_prtty
 , pg_relation_size('tracking') + pg_indexes_size('tracking') AS tab_and_idx_siz
 , pg_size_pretty(pg_relation_size('tracking') + pg_indexes_size('tracking')) AS tab_and_idx_siz_prtty
 , pg_total_relation_size('tracking') AS tot_rel_siz
 , pg_size_pretty(pg_total_relation_size('tracking')) AS tot_rel_siz_prtty
;
 tab_siz | tab_siz_prtty | idx_siz | idx_siz_prtty | tab_and_idx_siz | tab_and_idx_siz_prtty | tot_rel_siz | tot_rel_siz_prtty
------------+---------------+-----------+---------------+-----------------+-----------------------+-------------+-------------------
 2695716864 | 2571 MB | 753696768 | 719 MB | 3449413632 | 3290 MB | 3450101760 | 3290 MB

Nous voyons ici que les segments de table augmentent considérablement (+37 %), ce qui est appelé « bloat » dans la terminologie PostgreSQL. L’implémentation MVCC de PostgreSQL stocke à la fois l’ancienne et la nouvelle version de la ligne « in-place », c’est-à-dire directement dans la table, contrairement à MariaDB/MySQL qui stocke l’ancienne version dans l’espace UNDO et la nouvelle ligne « in-place ». Le fichier d’index augmente également de manière significative (+100 %). Nous devons encore approfondir nos recherches pour comprendre pourquoi. De plus, une « carte d’espace libre » est à nouveau créée (différence entre tot_rel_siz et tab_and_idx_siz).

Un VACUUM FULL réduit ensuite la taille de la table (à 28 %) et de l’index (à 50 %) par rapport à leur taille précédente:

postgres=# VACUUM FULL tracking;

postgres=# SELECT pg_relation_size('tracking') AS tab_siz
 , pg_size_pretty(pg_relation_size('tracking')) AS tab_siz_prtty
 , pg_indexes_size('tracking') AS idx_siz
 , pg_size_pretty(pg_indexes_size('tracking')) AS idx_siz_prtty
 , pg_relation_size('tracking') + pg_indexes_size('tracking') AS tab_and_idx_siz
 , pg_size_pretty(pg_relation_size('tracking') + pg_indexes_size('tracking')) AS tab_and_idx_siz_prtty
 , pg_total_relation_size('tracking') AS tot_rel_siz
 , pg_size_pretty(pg_total_relation_size('tracking')) AS tot_rel_siz_prtty
;
 tab_siz | tab_siz_prtty | idx_siz | idx_siz_prtty | tab_and_idx_siz | tab_and_idx_siz_prtty | tot_rel_siz | tot_rel_siz_prtty
-----------+---------------+-----------+---------------+-----------------+-----------------------+-------------+-------------------
 742916096 | 709 MB | 376864768 | 359 MB | 1119780864 | 1068 MB | 1119780864 | 1068 MB

et par rapport à leur taille d’origine, la table (à 38 %) et l’index (à 100 %) sont également plus petits. Il reste à déterminer pourquoi l’index est resté de la même taille et seule la table a diminué…

Essai 2: suppression des colonnes

Les colonnes sont ensuite supprimées à l’aide de DROP COLUMN.

postgres=# ALTER TABLE tracking
 DROP COLUMN d0, DROP COLUMN d1, DROP COLUMN d2, DROP COLUMN d3, DROP COLUMN d4
, DROP COLUMN d5, DROP COLUMN d6, DROP COLUMN d7, DROP COLUMN d8, DROP COLUMN d9
;

Comme la réponse a été immédiate, on peut supposer que cette opération est également instantanée. Malheureusement, je n’ai rien trouvé à ce sujet dans la documentation PostgreSQL.

La taille n’a pas changé de manière significative, ce qui est normal pour une opération instantanée. Cependant, le fait que la taille n’ait pas changé après la commande VACUUM FULL m’a un peu surpris:

 tab_siz | tab_siz_prtty | idx_siz | idx_siz_prtty | tab_and_idx_siz | tab_and_idx_siz_prtty | tot_rel_siz | tot_rel_siz_prtty
-----------+---------------+-----------+---------------+-----------------+-----------------------+-------------+-------------------
 742916096 | 709 MB | 376864768 | 359 MB | 1119780864 | 1068 MB | 1120010240 | 1068 MB

postgres=# VACUUM FULL tracking;

 tab_siz | tab_siz_prtty | idx_siz | idx_siz_prtty | tab_and_idx_siz | tab_and_idx_siz_prtty | tot_rel_siz | tot_rel_siz_prtty
-----------+---------------+-----------+---------------+-----------------+-----------------------+-------------+-------------------
 742916096 | 709 MB | 376864768 | 359 MB | 1119780864 | 1068 MB | 1119780864 | 1068 MB

Remarques

Le verrouillage dans PostgreSQL fonctionne comme suit:

VACUUM Les commandes DML concurrentes sont possibles, comme pour la commande OPTIMIZE TABLE de MariaDB/MySQL. Le résultat n’est toutefois pas tout à fait le même.
VACUUM FULL provoque un verrouillage ACCESS EXCLUSIVE. Comme pour MariaDB/MySQL 5.5 et versions antérieures avec la commande OPTIMIZE TABLE. Les commandes DML et SELECT ne sont PAS autorisées.

Sources

Essais supplémentaires

Au lieu de 0.0, NULL a été inséré dans les colonnes d0 à d9. La table est restée petite (tot_rel_siz_prtty = 1068 Mo). Il est donc également intéressant d’enregistrer NULL au lieu de valeurs fictives dans PostgreSQL.
Les colonnes d0 à d9 ont été créées avec DOUBLE PRECISION NOT NULL et remplies avec les valeurs 0.0. Sans effet: la table est restée volumineuse (tot_rel_siz_prtty = 2232 Mo).

Cette page a été traduite à l’aide de deepl.com.

Quelqu'un supprime mes segments de mémoire partagée !

oli.sennhauser@fromdual.com (Oli Sennhauser) — Sun, 08 Feb 2026 06:27:00 +0100

Lorsque nous travaillons avec PostgreSQL sous notre myEnv, nous obtenons régulièrement des erreurs de segment de mémoire partagée. Exemple:

psql: error: connection to server on socket "/tmp/.s.PGSQL.5433" failed:
FATAL: could not open shared memory segment "/PostgreSQL.4220847662":
No such file or directory

ou nous voyons des messages similaires dans le journal d’erreurs PostgreSQL:

ERROR: could not open shared memory segment "/PostgreSQL.4220847662":
No such file or directory

Comme je suis administrateur MariaDB/MySQL, je ne m’y connais pas très bien en matière de problèmes de mémoire partagée (MariaDB/MySQL ne fonctionne pas avec la mémoire partagée). Heureusement, une recherche sur Internet nous a mis sur une piste (source). On y trouve la mention suivante:

The documentation of systemd states that this only happens for non-system users. Can you check whether your “postgres” user (or whatever you are using) is a system user?

Utilisateur du système Linux

J’ai d’abord dû découvrir ce qu’était un utilisateur du système sous Linux. J’ai trouvé une réponse ici: What’s the difference between a normal user and a system user?.

That is not a technical difference but an organizational decision. E.g. it makes sense to show normal users in a login dialog (so that you can click them instead of having to type the user name) but it wouldn’t to show system accounts (the UIDs under which daemons and other automatic processes run) there.

La norme LSB indique à ce sujet: User ID Ranges:

The system User IDs from 0 to 99 should be statically allocated by the system, and shall not be created by applications.
The system User IDs from 100 to 499 should be reserved for dynamic allocation by system administrators and post install scripts using useradd.

Sur mon système Ubuntu, cela se présente comme suit:

$ grep SYS_ /etc/login.defs
#SYS_UID_MIN 100
#SYS_UID_MAX 999
#SYS_GID_MIN 100
#SYS_GID_MAX 999

Pour l’utilisateur PostgreSQL, cela serait également correct:

$ id postgres
uid=130(postgres) gid=142(postgres) groups=142(postgres),116(ssl-cert)

Mais comme l’instance PostgreSQL concernée fonctionne sous notre myEnv, c’est différent:

$ id dba
uid=1001(dba) gid=1001(dba) groups=1001(dba)

Nous avons donc maintenant deux possibilités:

Nous modifions SYS_UID_MAX et SYS_GID_MAX à 1001 (variante simple).
Ou nous modifions l’UID et le GID de notre utilisateur dba à moins de 1000.

Variante simple: modification de `SYS_UID_MAX` et `SYS_GID_MAX` à 1001

# /etc/login.defs
SYS_UID_MAX 1001
SYS_GID_MAX 1001

Par mesure de sécurité, la machine a été redémarrée. Mais cela n’a pas aidé: après peu de temps, les mêmes erreurs réapparaissent.

Variante plus compliquée: Modification de l’`UID` de 1001 à 990

$ cat /etc/passwd
...
polkitd:x:997:997:User for polkitd:/:/usr/sbin/nologin
systemd-coredump:x:998:998:systemd Core Dumper:/:/usr/sbin/nologin
tomcat:x:999:999:Apache Tomcat:/:/sbin/nologin
oli:x:1000:1000:Oli Sennhauser,,,:/home/oli:/bin/bash
dba:x:1001:1001:DBA user:/home/dba:/bin/bash
...

$ id dba
uid=1001(dba) gid=1001(dba) groups=1001(dba)

Pour cela, tous les processus de cet utilisateur doivent être arrêtés!

$ usermod --uid 990 dba
$ groupmod --gid 990 dba

$ find / -user 1001 -exec chown --no-dereference dba {} \;
$ find / -group 1001 -exec chgrp --no-dereference dba {} \;

Le problème semble ainsi résolu!

Informations supplémentaires

Une source mentionnée plus haut recommandait encore de définir les paramètres suivants dans systemd-logind:

# /etc/systemd/system/systemd-logind.service.d/override.conf
RemoveIPC=no
RuntimeDirectorySize=1%

Cette mesure n’est toutefois plus nécessaire, car cela fonctionne également sans cette modification.

Cette page a été traduite à l’aide de deepl.com.

Charger des fichiers CSV dans la base de données

oli.sennhauser@fromdual.com (Oli Sennhauser) — Fri, 06 Feb 2026 18:04:00 +0100

Récemment, j’ai voulu représenter sur une carte les lieux de résidence des membres de mon association (membres IGOC) pour un petit projet personnel. Je connaissais les adresses des membres de l’association, mais pas les coordonnées de leurs lieux de résidence.

Je me suis donc mis à la recherche des coordonnées et j’ai trouvé ce que je cherchais auprès de l’Office fédéral de topographie (swisstopo).

Les données y sont mises à disposition sous forme de fichier CSV. Détails ici : Coordonnées des localités suisses.

Comment charger ces données dans une base de données ?

Chargement des données avec MariaDB/MySQL

MariaDB et MySQL disposent pour cela de la commande LOAD DATA INFILE:

SQL> DROP TABLE IF EXISTS wgs84;

SQL> -- SET GLOBAL local_infile = ON; -- Only needed with MySQL

SQL> CREATE TABLE wgs84 (
 ortschaftsname VARCHAR(32)
, plz4 SMALLINT
, zusatzziffer SMALLINT
, zip_id SMALLINT UNSIGNED
, gemeindename VARCHAR(32)
, bfs_nr SMALLINT
, kantonskuerzel CHAR(2)
, adressenanteil varchar(8)
, e DOUBLE
, n DOUBLE
, sprache VARCHAR(8)
, validity VARCHAR(12)
);

SQL> -- TRUNCATE TABLE wgs84;

SQL> LOAD DATA LOCAL INFILE '/tmp/AMTOVZ_CSV_WGS84/AMTOVZ_CSV_WGS84.csv'
INTO TABLE wgs84
FIELDS TERMINATED BY ';'
LINES TERMINATED BY '\r\n'
IGNORE 1 LINES
;
Query OK, 5713 rows affected
Records: 5713 Deleted: 0 Skipped: 0 Warnings: 0

On peut ensuite consulter les données dans la base de données:

SQL> SELECT * FROM wgs84 ORDER BY ortschaftsname LIMIT 5;
+----------------+------+--------------+--------+--------------+--------+----------------+----------------+-------------------+--------------------+---------+------------+
| ortschaftsname | plz4 | zusatzziffer | zip_id | gemeindename | bfs_nr | kantonskuerzel | adressenanteil | e | n | sprache | validity |
+----------------+------+--------------+--------+--------------+--------+----------------+----------------+-------------------+--------------------+---------+------------+
| Aadorf | 8355 | 0 | 4672 | Aadorf | 4551 | TG | 96.802 % | 8.903193007810433 | 47.491079014637265 | de | 2008-07-01 |
| Aadorf | 8355 | 0 | 4672 | Elgg | 294 | ZH | 3.198 % | 8.89206766645808 | 47.4933781685032 | de | 2008-07-01 |
| Aarau | 5000 | 0 | 2913 | Aarau | 4001 | AG | 99.713 % | 8.048148371736266 | 47.38973523857376 | de | 2008-07-01 |
| Aarau | 5000 | 0 | 2913 | Suhr | 4012 | AG | 0.287 % | 8.059410934099922 | 47.383298214804334 | de | 2008-07-01 |
| Aarau | 5004 | 0 | 2932 | Aarau | 4001 | AG | 100 % | 8.060698546432551 | 47.400587704180744 | de | 2008-07-01 |
+----------------+------+--------------+--------+--------------+--------+----------------+----------------+-------------------+--------------------+---------+------------+
5 rows in set

Ou plus précisément :

SQL> SELECT ortschaftsname AS city, plz4 AS city_code, e AS lon, n AS lat
 FROM wgs84 WHERE plz4 IN (8280, 4663, 6043);
+-------------+-----------+-------------------+--------------------+
| city | city_code | lon | lat |
+-------------+-----------+-------------------+--------------------+
| Aarburg | 4663 | 7.904271716719409 | 47.321443418782955 |
| Aarburg | 4663 | 7.889249714098425 | 47.313536073562474 |
| Aarburg | 4663 | 7.880309179095798 | 47.31255194439023 |
| Adligenswil | 6043 | 8.364849060491428 | 47.07037816052481 |
| Kreuzlingen | 8280 | 9.173740257895282 | 47.64491046067056 |
| Kreuzlingen | 8280 | 9.159171428030783 | 47.654149879509134 |
| Kreuzlingen | 8280 | 9.204470741840725 | 47.639949130372145 |
+-------------+-----------+-------------------+--------------------+
7 rows in set (0.003 sec)

Je laisse le soin au lecteur ou à la lectrice de supprimer les doublons… :-)

Jusqu’ici tout va bien, passons maintenant aux subtilités:

Différences entre MariaDB et MySQL

La procédure décrite ci-dessus fonctionne parfaitement avec MariaDB 11.4 et 11.8. Avec MySQL 8.4, il existe de légères différences:

Le premier message d’erreur qui empêche le chargement est le suivant:

ERROR 3948 (42000): Loading local data is disabled; this must be enabled on both the client and server sides

Il peut être contourné assez facilement à l’aide de la commande:

SQL> SET GLOBAL local_infile = ON;

Lors de la tentative suivante, vous échouerez comme suit:

ERROR 2068 (HY000): LOAD DATA LOCAL INFILE file request rejected due to restrictions on access.

Ce problème peut être résolu en démarrant le client MySQL comme suit:

$ mysql --local-infile=1 --user=root test

Sources

MariaDB: LOAD DATA INFILE
MySQL: LOAD DATA Statement

Chargement des données avec PostgreSQL

PostgreSQL dispose pour cela de la commande COPY ... FROM:

postgres=# DROP TABLE IF EXISTS wgs84;

postgres=# CREATE TABLE wgs84 (
 ortschaftsname VARCHAR(32)
, plz4 SMALLINT
, zusatzziffer SMALLINT
, zip_id INT
, gemeindename VARCHAR(32)
, bfs_nr SMALLINT
, kantonskuerzel CHAR(2)
, adressenanteil varchar(8)
, e DOUBLE PRECISION
, n DOUBLE PRECISION
, sprache VARCHAR(8)
, validity VARCHAR(12)
);

postgres=# -- TRUNCATE TABLE wgs84;

postgres=# COPY wgs84
FROM '/tmp/AMTOVZ_CSV_WGS84/AMTOVZ_CSV_WGS84.csv'
DELIMITER ';'
CSV HEADER
;
COPY 5713

Ici aussi, nous obtenons le résultat attendu sous la forme habituelle pour PostgreSQL:

postgres=# SELECT ortschaftsname AS city, plz4 AS city_code, e AS lon, n AS lat
 FROM wgs84 WHERE plz4 IN (8280, 4663, 6043);
 city | city_code | lon | lat
-------------+-----------+-------------------+--------------------
 Aarburg | 4663 | 7.904271716719409 | 47.321443418782955
 Aarburg | 4663 | 7.889249714098425 | 47.313536073562474
 Aarburg | 4663 | 7.880309179095798 | 47.31255194439023
 Adligenswil | 6043 | 8.36487538940682 | 47.07037794822416
 Kreuzlingen | 8280 | 9.173740257895282 | 47.64491046067056
 Kreuzlingen | 8280 | 9.159171428030783 | 47.654149879509134
 Kreuzlingen | 8280 | 9.204470741840725 | 47.639949130372145
(7 rows)

Sources

PostgreSQL: COPY

Petites différences entre MariaDB/MySQL et PostgreSQL

En principe, la commande de chargement est complètement différente dans les deux univers de bases de données.

Avec MariaDB et PostgreSQL, les commandes fonctionnent « prêtes à l’emploi ». MySQL a intégré deux obstacles de sécurité supplémentaires.

PostgreSQL ne connaît pas les types de données entières UNSIGNED, il faut donc utiliser le type de données immédiatement supérieur (INT), ce qui est un peu moins économe en espace que avec MariaDB/MySQL.

Remarques

Lorsque nous avons effectué le même test il y a quelques jours, une erreur s’est produite lors du chargement. Il semble donc que la source de données ait également subi une modification minime…

Je n’ai pas pu déterminer rapidement s’il existe une norme SQL pour ces commandes de chargement et, si oui, si MariaDB/MySQL ou PostgreSQL sont conformes à cette norme.

Et bien sûr, il existe d’autres moyens d’importer vos données CSV dans la base de données…

Les outils mariadb-import/mysqlimport sont utilisés si vous souhaitez effectuer cette opération à partir de la ligne de commande. Le moteur de stockage CSV peut également être utilisé à cette fin (pour plus de détails, voir ici). Une variante officiellement prise en charge est le moteur de stockage MariaDB CONNECT avec le type CSV (voir ici):

SQL> INSTALL SONAME 'ha_connect';

SQL> CREATE TABLE wgs84_fdw
ENGINE = CONNECT
table_type = CSV
file_name='/tmp/AMTOVZ_CSV_WGS84/AMTOVZ_CSV_WGS84.csv'
header = 1
sep_char = ';'
quoted = 0;

SQL> INSERT INTO wgs84 SELECT * FROM wgs84_fdw;

Il semblerait que le moteur de stockage CONNECT de MariaDB ne soit malheureusement plus pris en charge? Et l’outil mydumper/myloader semble également pouvoir traiter les fichiers CSV.

Et bien sûr, tout cela peut également être résolu de manière applicative…

Avec PostgreSQL, les possibilités suivantes existent:

postgres=# \copy wgs84 FROM '/tmp/AMTOVZ_CSV_WGS84/AMTOVZ_CSV_WGS84.csv' DELIMITER ';' CSV HEADER

puis depuis le shell:

$ psql --user=dba -c "\copy wgs84 FROM '/tmp/AMTOVZ_CSV_WGS84/AMTOVZ_CSV_WGS84.csv' DELIMITER ';' CSV HEADER"

Et la variante via le Foreign Data Wrapper (FWD). Mais je ne l’ai pas essayée:

postgres=# CREATE EXTENSION postgres_fdw;

postgres=# CREATE SERVER foreign_server
 FOREIGN DATA WRAPPER postgres_fdw
 OPTIONS (
 datasource 'CSV:/tmp/AMTOVZ_CSV_WGS84/AMTOVZ_CSV_WGS84.csv',
 format 'CSV'
 )
;

postgres=# CREATE USER MAPPING FOR local_user
 SERVER foreign_server
 OPTIONS (user 'foreign_user', password 'password')
;

postgres=# CREATE FOREIGN TABLE foreign_table (
 id integer NOT NULL,
 data text
)
 SERVER foreign_server
 OPTIONS (schema_name 'some_schema', table_name 'some_table')
;

Addendum

Le type de données MariaDB/MySQL DOUBLE s’appelle DOUBLE PRECISION dans PostgreSQL.

Cette page a été traduite à l’aide de deepl.com.

FromDual

oli.sennhauser@fromdual.com (Oli Sennhauser) — Wed, 21 Jan 2026 11:37:08 +0100

Services neutres et indépendants des fabricants
pour MariaDB, Galera Cluster et MySQL !

Services pour MariaDB, Galera et MySQL

Nous proposons les services suivants :

Conseil neutre et indépendant des fabricants pour MariaDB, Galera Cluster, MySQL et Percona Server.
Abonnements au support Enterprise pour MariaDB, Galera Cluster et MySQL.
Formations/séminaires MariaDB, Galera et MySQL pour les administrateurs de bases de données (DBA) et les développeurs.
Grâce à nos services remote-DBA, nous vous aidons à exploiter vos bases de données MariaDB et MySQL critiques pour votre activité.
Nos produits logiciels : OpsCenter, Performance Monitor, Backup/Recovery Manager et myEnv vous assistent dans l’exploitation de votre infrastructure.

Pour plus d’informations, contactez-nous…

Testez gratuitement notre service de surveillance

Formations MariaDB, Galera et MySQL prévues

Pour plus d’informations sur notre programme de formation continue, consultez la rubrique Formations/séminaires MariaDB, Galera et MySQL.

' . 'ERROR: Snipped currently unavailable!' . '

' . "\n"; error_log('File: ' . $file . ' does NOT exist.'); } ?>

Actualités FromDual

Pour suivre l’actualité de FromDual, suivez-nous sur:

LinkedIn, X / Twitter, Facebook, Bluesky ou Mastodon.

Cette page a été traduite avec deepl.com.

Test

oli.sennhauser@fromdual.com (Oli Sennhauser) — Wed, 21 Jan 2026 11:27:30 +0100

Une page test en allemand…

Contacter FromDual

oli.sennhauser@fromdual.com (Oli Sennhauser) — Fri, 16 Jan 2026 20:42:00 +0100

Vous pouvez nous contacter comme suit:

Adresse:	FromDual GmbH Rebenweg 6 CH - 8610 Uster Suisse
E-mail:	contact@fromdual.com
Téléphone:	+41 44 500 58 20	+49 201 853 67 70

Numéro de TVA/UID:	CHE-301.341.221 MWST
Numéro DUNS:	485921436

InnoDB deadlock sur SELECT? Pas possible! Ou bien si?

oli.sennhauser@fromdual.com (Oli Sennhauser) — Sat, 25 Nov 2023 17:33:39 +0000

Introduction

Deux points pour commencer:

Un deadlock est un état dans lequel deux transactions différentes ne sont plus en mesure de continuer à travailler, car chaque transaction détient un verrou dont l’autre transaction aurait besoin. Comme les deux transactions attendent que l’autre libère son verrou, aucune des deux transactions ne libérera son verrou. Et cela durerait jusqu’à la saint-glinglin. Pour éviter cela, l’instance MariaDB intervient et tue rapidement la transaction qui a fait le moins de travail. L’application reçoit alors un message d’erreur de type “deadlock”:
```
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
```
Dans l’écosystème MariaDB, il est généralement admis qu’un SELECT ne provoque pas de verrouillage (exception : FOR UPDATE ou LOCK IN SHARE MODE) et ne peut donc pas faire partie d’un deadlock.

Le problème

Un client de longue date se présente à l’équipe DBA à distance de FromDual en lui demandant d’expliquer une situation de deadlock:

Bonjour l’équipe FromDual, J’ai à nouveau besoin de votre expertise sur le thème des deadlocks. Quand cela vous conviendrait-il ?

La situation est la suivante: La transaction 1 consiste en un simple INSERT. La transaction 2 consiste en un SELECT. Cela ne devrait PAS provoquer de blocage.

Nous vérifions d’abord les points suivants:

Toutes les tables concernées par ces requêtes sont-elles correctement indexées? Oui, elles le sont. Les requêtes fonctionnent toutes parfaitement!
Les requêtes SELECT font-elles éventuellement partie d’une transaction d’envergure (transaction NON auto-commit) et ne sont-elles donc pas la cause réelle du blocage? Non, ce n’est pas le cas. Il s’agit de transactions autocommit.

Que faire maintenant? Ce qu’il faut encore préciser: Le SELECT est lancé à une cadence très élevée, c’est-à-dire environ toutes les 5 ms!

Il est évident que l’INSERT génère des verrous. C’est d’ailleurs affiché. Mais pourquoi l’ordre SELECT génère-t-il des verrous? Ceux-ci sont également affichés!

Nous essayons donc de résoudre le problème en plusieurs étapes.

Méthode de résolution

La requête se présente comme suit:

SQL> SET @id = (SELECT id FROM test WHERE id = 3);

Si nous plaçons cette requête dans une transaction explicite, nous pouvons même voir les verrous :

SQL> START TRANSACTION;
SQL> SET @id = (SELECT id FROM test WHERE id = 3);

et dans une deuxième connection:

SQL> SELECT * FROM information_schema.INNODB_TRX<br>G
*************************** 1. row ***************************
 trx_id: 0
 trx_state: RUNNING
 trx_started: 2023-11-19 15:27:09
 trx_requested_lock_id: NULL
 trx_wait_started: NULL
 trx_weight: 2
 trx_mysql_thread_id: 3765
 trx_query: NULL
 trx_operation_state:
 trx_tables_in_use: 0
 trx_tables_locked: 1
 trx_lock_structs: 2
 trx_lock_memory_bytes: 1128
 trx_rows_locked: 1
 trx_rows_modified: 0
 trx_concurrency_tickets: 0
 trx_isolation_level: REPEATABLE READ
 trx_unique_checks: 1
 trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
 trx_is_read_only: 0
trx_autocommit_non_locking: 0

Malheureusement, nous ne voyons pas de quel type de verrou (IS) il s’agit, car la vue INNODB_LOCKS est vide.

La solution

Si nous faisons la même tentative avec des SELECT “normaux”:

SQL> START TRANSACTION; SELECT id FROM test WHERE id = 3;

SQL> START TRANSACTION; SELECT id INTO @id FROM test WHERE id = 3;

nous ne voyons AUCUN verrouillage:

SQL> SELECT * FROM information_schema.INNODB_TRX<br>G
*************************** 1. row ***************************
 trx_id: 0
 trx_state: RUNNING
 trx_started: 2023-11-19 15:31:35
 trx_requested_lock_id: NULL
 trx_wait_started: NULL
 trx_weight: 0
 trx_mysql_thread_id: 3765
 trx_query: NULL
 trx_operation_state:
 trx_tables_in_use: 0
 trx_tables_locked: 0
 trx_lock_structs: 0
 trx_lock_memory_bytes: 1128
 trx_rows_locked: 0
 trx_rows_modified: 0
 trx_concurrency_tickets: 0
 trx_isolation_level: REPEATABLE READ
 trx_unique_checks: 1
 trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
 trx_is_read_only: 0
trx_autocommit_non_locking: 0

Il semble donc que la construction SET @id = (...) provoque ce verrou IS. Le client réécrit son application et peu après, nous recevons le message suivant:

Bonjour l’équipe FromDual, Votre conseil était le bon. Plus de deadlocks depuis vendredi midi. Merci et bon week-end.

Autres questions résolues

MySQL 8.0 se comporte de la même manière ? Oui, exactement de la même manière.

Addendum

Mon cher collègue Matthias m’a donné une autre idée de suite: qu’en est-il des procédures stockées et des fonctions stockées de MariaDB?

Les deux tests ici:

DELIMITER //

CREATE OR REPLACE PROCEDURE locktestsp (INOUT id INT)
BEGIN
 SELECT id INTO id FROM test WHERE id = id LIMIT 1;
END;
//

DELIMITER ;

SET @id = 3;
START TRANSACTION;
CALL locktestsp(@id);
SELECT @id;

SELECT trx_tables_locked, trx_lock_structs, trx_rows_locked FROM information_schema.INNODB_TRX;
+-------------------+------------------+-----------------+
| trx_tables_locked | trx_lock_structs | trx_rows_locked |
+-------------------+------------------+-----------------+
| 0 | 0 | 0 |
+-------------------+------------------+-----------------+

et ici:

DELIMITER //

CREATE OR REPLACE FUNCTION locktestsf (IN id INT)
RETURNS CHAR(50) DETERMINISTIC
BEGIN
 SELECT id INTO id FROM test WHERE id = id LIMIT 1;
 RETURN id;
END;
//

DELIMITER ;

START TRANSACTION;
SELECT locktestsf(3);

 SELECT trx_tables_locked, trx_lock_structs, trx_rows_locked FROM information_schema.INNODB_TRX;
+-------------------+------------------+-----------------+
| trx_tables_locked | trx_lock_structs | trx_rows_locked |
+-------------------+------------------+-----------------+
| 0 | 0 | 0 |
+-------------------+------------------+-----------------+

Cette page a été traduite à l’aide de deepl.com.

Les blogs FromDual

oli.sennhauser@fromdual.com (Oli Sennhauser) — Fri, 26 Mar 2010 10:20:30 +0100

Sur cette page, vous trouverez les différents blogs des collaborateurs de FromDual ainsi que quelques agrégats de blogs utiles.

Blogs des employés de FromDual

Blog d’Oli en allemand

Blog de Shinguz en anglais

Blog d’Abdel-Mawla en anglais

Blog de Jörg en anglais

Blog de Cédric en anglais

Blog commercial de FromDual en allemand

Blog commercial de FromDual en anglais

Agrégateurs de blogs FromDual

FromDual AllFeed en allemand

FromDual AllFeed en anglais

FromDual TechFeed en allemand

FromDual TechFeed en anglais

FromDual InfoFeed en allemand

FromDual InfoFeed en anglais

MySQL Tech-Feed en allemand

MySQL Tech-Feed en anglais

PostgreSQL Tech-Feed en allemand

PostgreSQL Tech-Feed en anglais

Cette page a été traduite avec deepl.com.

Oups! Page introuvable.

oli.sennhauser@fromdual.com (Oli Sennhauser) — Mon, 01 Jan 0001 00:00:00 +0000

Que cherches-tu exactement?

oli.sennhauser@fromdual.com (Oli Sennhauser) — Mon, 01 Jan 0001 00:00:00 +0000

FromDual GmbH

Comment charger rapidement des données dans la base de données ?

Variante 1: INSERT et DELETE (forme la plus simple)

Variante 2: START TRANSACTION et INSERT et DELETE

Variante 3: START TRANSACTION et INSERT et DELETE optimisés

Configuration du test

Préparation et exécution avec MariaDB/MySQL

Préparation et exécution avec PostgreSQL

Résultats

Remarques

Autres articles

MariaDB a détruit le concept du buffer pool configurable dynamiquement !

Description du problème

Comment cela fonctionnait-il auparavant ?

Que fait MariaDB aujourd’hui ?

Comment PostgreSQL procède-t-il ?

Commentaires

Combien d'espace NULL occupe-t-il?

Essai avec MariaDB/MySQL

Montage expérimental

Défragmentation du tableau

Essai 1: mise à NULL

Essai 2: suppression des colonnes

Conclusion

Essai avec PostgreSQL

Montage expérimental

Essai 1: mise à NULL

Essai 2: suppression des colonnes

Remarques

Sources

Essais supplémentaires

Quelqu'un supprime mes segments de mémoire partagée !

Utilisateur du système Linux

Variante simple: modification de SYS_UID_MAX et SYS_GID_MAX à 1001

Variante plus compliquée: Modification de l’UID de 1001 à 990

Informations supplémentaires

Charger des fichiers CSV dans la base de données

Chargement des données avec MariaDB/MySQL

Différences entre MariaDB et MySQL

Sources

Chargement des données avec PostgreSQL

Sources

Petites différences entre MariaDB/MySQL et PostgreSQL

Remarques

Addendum

FromDual

Services pour MariaDB, Galera et MySQL

Formations MariaDB, Galera et MySQL prévues

Actualités FromDual

Test

Contacter FromDual

InnoDB deadlock sur SELECT? Pas possible! Ou bien si?

Introduction

Le problème

Méthode de résolution

La solution

Autres questions résolues

Addendum

Les blogs FromDual

Blogs des employés de FromDual

Agrégateurs de blogs FromDual

Oups! Page introuvable.

Variante 1: `INSERT` et `DELETE` (forme la plus simple)

Variante 2: `START TRANSACTION` et `INSERT` et `DELETE`

Variante 3: `START TRANSACTION` et `INSERT` et `DELETE` optimisés

Essai 1: mise à `NULL`

Essai 1: mise à `NULL`

Variante simple: modification de `SYS_UID_MAX` et `SYS_GID_MAX` à 1001

Variante plus compliquée: Modification de l’`UID` de 1001 à 990