Discussion :

[ouldfella]

bonjour,
j'ai lu sur le FAQ :

Une table peut contenir jusqu'à 4096 colonnes. Évidemment, une table avec un grand nombre de colonnes aura un impact sur les performances.

j'ai une table qui a 30 colonnes, j'ai créé une autre table ayant 10 colonnes alors que je peux mettre ces colonne dans la première table
je sais pas comment le nombre de colonnes a un impact sur la performance de moment que je fais une requête SELECT que sur les colonnes désirés

merci d'avance

[SQLpro]

Lisez l'article que j'ai écrit à ce sujet : https://blog.developpez.com/sqlpro/p...mances_petites

A +

[ouldfella]

merci beaucoup,
l'article m'a vraiment aidé à comprendre certaines nouvelles chose
je vais opter à de petites tables normalisées pour les meilleures performances

[scamphp]

Bonjour

Quand vous parlez de table obèses vous parlez uniquement en nombre de colonnes (champs) ou en poids des contenus.

1°) Si j'ai 200 champs avec peu d'info dans les champs, suis-je une table obèse ?

2°) Si j'ai 10 champs mais que j'ai beaucoup de contenu texte dans un de mes champs, suis-je aussi une tableau obèse ???

[CinePhil]

Lisez l'article de SQLPro !

200 colonnes (et pas champs) dans une table, c'est énorme !
C'est souvent le signe d'une mauvaise modélisation des données si la table dépasse quelques dizaines de colonnes.

Par contre, une table avec peu de colonnes mais des colonnes contenant du texte, ça peut être nécessaire. C'est la cas des tables des CMS ou des forums, par exemple, et, bien que la plupart des modèles de données de ces logiciels ne soient pas top, ça ne pose pas de problèmes. Il est normal de stocker les textes de nos parfois longs messages de forums dans la base de données.

L'essentiel, c'est de bien modéliser les données.

[scamphp]

Et donc la question qui tue lol... tout cela pour en arriver la

C'est la cas des tables des CMS ou des forums, par exemple, et, bien que la plupart des modèles de données de ces logiciels ne soient pas top, ça ne pose pas de problèmes.

Pour faire mieux que pas top... ça serait quoi l'idée

Car quand on réalise sa base POST, CATEGORY.... la 1ere idée c'est de se calquer sur ce qu'il se fait au niveau des CMS...

Mais la 2ème idée c'est de se dire puisque je fais ma propre base, n'y aurait-il pas des piste à améliorer (j'ai moins de fonction, j'ai pas besoin d'être compatible ou rétrocompatible...)

Quand vous dites que les modèles des CMS ne sont pas top... il faudrait faire quoi pour avoir une Bdd POST et CATEGORY au top

Un regard critique sur la bd WP serait intéressant car au moins tout le monde parle de la même chose (n'ayant pas encore finalisé mon projet et en plus tout le monde s'en fiche de mon projet) alors qu'une étude de cas sur une base que tout le monde connait ça c'est plus constructif

[Artemus24]

Salut à tous.

L'essentiel, c'est de bien modéliser les données.

Non, vous n'avez pas compris le message de SQLPRO. La règle c'est la performance !
Et pour arriver à une bonne performance, vous devez au préalable modéliser votre base de données.

D'ailleurs SQLPRO le dit :

La normalisation d’une base de données (c’est-à-dire le respect des règles de modélisation) n’est pas une figure de style. C’est, avant tout, une question de performance !

Bref, pour ne pas avoir respecter l’art de la modélisation des données, les performances deviendront tôt ou tard un cauchemar !

Et parfois, pour améliorer les perfomances, il est nécessaire de dégrader la base de données. Mais bon, ça c'est un autre problème.
Donc, non, c'est pas l'essentiel, mais juste une condition nécessaire et non suffisante !

Lisez l'article de SQLPro !

C'est ce que scamphp a fait, d'où sa question sur ce que l'on nomme une table obèse.

Je réponds à sa question.
Dans cette article, nous nous trouvons dans la modélisation et le problème soulevé est bien le nombre de colonnes d'une table.
Il faut externaliser les colonnes en fonction de leur fréquence d'utilisation, mais aussi de leur pertinence.
L'exemple classique des adresses, des numéros de téléphones, qui enfreingnent les formes normales. Pourquoi ?
Par ce qu'une personne peut avoir de 0 à N numéros de téléphones. Même remarque pour les adresses.

Pour la volumétrie, il s'agit plutôt d'une question technique et la solution est d'utiliser des partitions.

Pour faire mieux que pas top... ça serait quoi l'idée

Il n'y a pas de solutions générales, mais que des cas particuliers.
L'exemple est d'externaliser les messages dans une table dédiée à cela.

Car quand on réalise sa base POST, CATEGORY.... la 1ere idée c'est de se calquer sur ce qu'il se fait au niveau des CMS...

NON !

Quand vous dites que les modèles des CMS ne sont pas top... il faudrait faire quoi pour avoir une Bdd POST et CATEGORY au top

C'est avant tout un problème de modélisation et de performance.
On ne peut pas répondre simplement à une question d'ordre générale.

Si je prends le cas donnée par SQLPRO sur le numéro de la sécurité sociale, il faut au préalable se poser quelques questions.
Du genre, les recherches que vous désirez faire sur cette colonne.
Si vous ne faites jamais rien, alors une seule colonne de type char peut suffire.
Si vous avez besoin de faire des recherches plus fine, il est nécessaire d'éclater le numéro de sécurité sociale en plusieurs petites colonnes.
C'est le besoin que vous avez, qui va conditionner la représentation de vos données dans votre base.

Donc non, il n'y a pas de solutions toutes faites

Ne confondez pas le stockage des données, son exploitation et sa présentation.

@+

[CinePhil]

Par exemple, concernant le modèle de données de Wordpress...
Dans la table wp_users (qui devrait être nommée au singulier) :
- colonne user_pass en VARCHAR(255)... je ne voudrais pas être l'utilisateur qui ait un mot de passe à 255 caractères !
- colonne ID en UNSIGNED BIGINT soit un potentiel de 2^64 utilisateurs !!! Que celui qui fait un site avec Wordpress à plus de 4 milliards d'utilisateurs (taille du UNSIGNED INT) se fasse connaître ! En attendant, c'est 2 fois plus de place (8 octets au lieu de 4 par ligne) pour stocker ça dans cette table et en tant que clé étrangère dans beaucoup d'autres.

Et une table wp_usermeta (pourquoi pas !) mais qui stocke des propriétés qui peuvent s'appliquer à tous les users ou presque. Donc des meta_key en VARCHAR(255) qui se répètent pour un très grand nombre, voire la totalité des utilisateurs.

Dans la table wp_posts (qui devrait être nommée au singulier) :
- une colonne post_status en VARCHAR(20) alors que la liste des status possibles est limitée et devrait faire l'objet d'une table de référence séparée ;
- idem pour la colonne post_type...

Et des dénormalisations de la sorte, j'en ai trouvé dans les BDD de Wordpress, Joomla, Drupal, Joomla, GLPI, PMB, Moodle...

Avec en plus une programmation objet utilisant un ORM qui génère une masse de requêtes beaucoup plus grande que le nécessaire, ça finit par donner des sites lents qui nécessitent des ressources machines plus importantes.
Alors qu'avec un bon modèle de données, n'importe quelle requête, même un tant soit peu complexe, s'exécutera en une fraction de seconde, même avec des millions de lignes et une machine qui n'est pas une bête de course. À titre d'exemple, encore, j'ai développé, il y a 10 ans, une base de données à partir de fichiers plats extraits de deux années du ficher national d'identification des bovins. 63 millions de bovins, des milliers d'éleveurs, des millions de mouvements de bovins (vente, exportation, importation, abattage...) et toutes mes requêtes s'exécutaient au plus en quelques secondes sur un petit serveur de l'époque qui ne contenait pas que cette base données.

[Artemus24]

Salut CinePhil.

colonne user_pass en VARCHAR(255)... je ne voudrais pas être l'utilisateur qui ait un mot de passe à 255 caractères !

Je vous signale que plus le mot de passe est long et plus il est difficile de le cracker. Donc non, cela ne me choque pas.

colonne ID en UNSIGNED BIGINT soit un potentiel de 2^64 utilisateurs !!!

C'est grand, je le reconnais. Mais rien n'indique que la colonne en question soit auto incrémenté. Si ce type existe, ce n'est pas sans raison.

Que celui qui fait un site avec Wordpress à plus de 4 milliards d'utilisateurs (taille du UNSIGNED INT) se fasse connaître !

Vous portez un jugement de valeur sans comprendre la problématique de l'utilisateur qui aura besoin de ce type.

En attendant, c'est 2 fois plus de place (8 octets au lieu de 4 par ligne) pour stocker ça dans cette table et en tant que clé étrangère dans beaucoup d'autres.

Oui et alors ? Ce n'est pas parce que vous pouvez mettre 4 milliards d'utilisateurs que cela sera le cas.
On arrive sur des vieux forums, à obtenir plus de 90% d'utilisateurs inactifs.

Et une table wp_usermeta (pourquoi pas !) mais qui stocke des propriétés qui peuvent s'appliquer à tous les users ou presque. Donc des meta_key en VARCHAR(255) qui se répètent pour un très grand nombre, voire la totalité des utilisateurs.

Là, je suis d'accord avec vous. C'est pas du tout performant comme approche !!!

Dans la table wp_posts (qui devrait être nommée au singulier) :
- une colonne post_status en VARCHAR(20) alors que la liste des status possibles est limitée et devrait faire l'objet d'une table de référence séparée ;
- idem pour la colonne post_type...

Je suis encore d'accord avec vous.

Et des dénormalisations de la sorte, j'en ai trouvé dans les BDD de Wordpress, Joomla, Drupal, Joomla, GLPI, PMB, Moodle...

Ce ne sont pas des dénormalisations, c'est du grand n'importe quoi. Nuance.
La dénormalisation a pour but d'améliorer les performances et non le contraire.

Alors qu'avec un bon modèle de données, n'importe quelle requête, même un tant soit peu complexe, s'exécutera en une fraction de seconde, même avec des millions de lignes et une machine qui n'est pas une bête de course.

N'exagérez pas ! Un modèle de données n'est pas la panacée aux problèmes de performances. Elles y contribuent grandement.
Et que faites-vous des aspects techniques qui ne rentre pas dans la modélisation ? Index, partitions, ...

À titre d'exemple, encore, j'ai développé, il y a 10 ans, une base de données à partir de fichiers plats extraits de deux années du ficher national d'identification des bovins. 63 millions de bovins, des milliers d'éleveurs, des millions de mouvements de bovins (vente, exportation, importation, abattage...) et toutes mes requêtes s'exécutaient au plus en quelques secondes sur un petit serveur de l'époque qui ne contenait pas que cette base données.

C'est ça votre performance ???

J'ai participé à la numérisation des chèques à la société général en DB2 sur gros système IBM TSP/ISPF en cobol, et ce, avant l'an 2000.
Il y a chaque jours des millions de chèques et l'on archive, sur un minimum de 10 ans.
Le temps de réponse pour la consultation doit être inférieur à la seconde.
Et ce, quelque soit le lieu où se fait la consultation en France !

@+

[CinePhil]

Je vous signale que plus le mot de passe est long et plus il est difficile de le cracker. Donc non, cela ne me choque pas.

Il y a une marge entre un Mot_2_Pass de 10 caractères mélangeant lettres capitales et minuscules, chiffres, signes, facile à retenir et rapide à taper, et un_mot_de_passe_qu_on_retient_mais_qui_est_chiant_comme_la_pluie_a_taper (<== 73 caractères) !

C'est grand, je le reconnais. Mais rien n'indique que la colonne en question soit auto incrémenté. Si ce type existe, ce n'est pas sans raison.

Et bien si, c'est auto incrémenté. À moins que Worpress ait des ambitions interplanétaires ?

Vous portez un jugement de valeur sans comprendre la problématique de l'utilisateur qui aura besoin de ce type.

Et vous vous portez un jugement de valeur sur mon commentaire sans l'avoir étudié !

Oui et alors ? Ce n'est pas parce que vous pouvez mettre 4 milliards d'utilisateurs que cela sera le cas.

Même avec quelques milliers d'utilisateurs ça fera deux fois plus de place... reportée sur toutes les tables où l'identifiant de l'utilisateur est clé étrangère.
On peut vite atteindre des mégaoctets supplémentaires inutiles.

Ce ne sont pas des dénormalisations, c'est du grand n'importe quoi. Nuance.
La dénormalisation a pour but d'améliorer les performances et non le contraire.

Oui, si vous voulez. C'est un modèle de données non normalisé, aurais-je dû écrire.

N'exagérez pas ! Un modèle de données n'est pas la panacée aux problèmes de performances. Elles y contribuent grandement.
Et que faites-vous des aspects techniques qui ne rentre pas dans la modélisation ? Index, partitions, ...

Vous chipotez ! Dans mon esprit, le bon modèle de données entraîne déjà une bonne partie de la bonne indexation. Si le modèle est du niveau conceptuel, l'indexation vient évidemment au niveau de la fabrication puis de la maintenance de la BDD et doit aussi être entreprise avec soin.
À noter que des logiciels de modélisation prévoient aussi l'indexation car ils génèrent le code SQL de la BDD. Lorsque je modélise, je pense déjà à l'indexation. J'essaie d'éviter les index inutiles et j'imagine déjà quels seront ceux pertinents à ajouter (notamment les multi-colonnes).

C'est ça votre performance ???

Ce n'était qu'un exemple réalisé avec peu de moyens. J'étais en stage d'ingénieur CNAM dans un service d'analyse de l'INRA à l'époque et la BDD était pour un thésard. Et, de mémoire, le temsp de réponse que j'évoque dépassant la seconde était peut-être sur mon ordinateur portable de l'époque, avant que la BDD fut transférée sur le serveur de développement.
Bref...

Votre exemple est en effet plus parlant.

[scamphp]

Voila pourquoi c'est compliqué pour un débutant en auto-formation... car personne n'est jamais d'accord sur rien lol

Alors c'est pour cela que je pose mes petites questions... et que parfois je les reposes...

Si je pose 3 fois la questions j'ai 3 réponses différentes lol après je fais le tris

[CinePhil]

La réponse à votre question d'origine est quand même qu'il faut éviter les tables avec beaucoup de colonnes.
En bonus, nous vous conseillons fortement de réaliser un modèle de données normalisé. Ça évitera déjà pas mal de problèmes de performances.

[scamphp]

Merci Artemus24 et CinePhil d'avoir des avis et points de vues différents.

Il me reste un dernier point un peu flou

C'est la notion de poids d'une colonne ne servant pas à une recherche.

Si j'ai 1 000 enregistrements avec des colonnes qui contiennent ID : 1ko / Champ1: 1Ko / Champ2 : 2Ko / Champ3: 1Ko / Champ4 : 500Ko

si je veux chercher le CHamp1 de l'ID 1000 -> Msql va devoir charger la table soit (1k0+1ko+1ko+500ko) x 1000 pour chercher l'ID et lire la ligne OU BIEN il ne charge pas la table et se contente de lire la colonne ID et Colonne Champ1 (le champ4 plus lourd n'intervenant pas il n'est pas chargé).

Si le champ4 plus lourd est changé automatiquement avec la table

ne faudrait-il pas séparer les colonnes légères et lourdes MEME si on n'a pas beaucoup de colonnes

ID : 1ko/ IDKEY : 1ko / Champ1: 1Ko / Champ2 : 1Ko / Champ3: 1Ko
IDKEY : 1ko / Champ4 : 500ko

C'est théorique mais c'est pour être sur de comprendre ce que charge Mysql (et comment il le charge, car pour structurer un bdd avant il faut comprendre le mécanisme)

[Artemus24]

Salut CinePhil.

Vous chipotez ! Dans mon esprit, le bon modèle de données entraîne déjà une bonne partie de la bonne indexation.

C'est faux, car vous confondez modélisation et aspect technique en vue d'améliorer les performances. Donc non, je ne chipote pas.

Si le modèle est du niveau conceptuel, l'indexation vient évidemment au niveau de la fabrication puis de la maintenance de la BDD et doit aussi être entreprise avec soin.

Je ne comprends rien à votre phrase.

À noter que des logiciels de modélisation prévoient aussi l'indexation car ils génèrent le code SQL de la BDD.

Peut-être tant que l'on reste dans une modélisation standard.
Mais le rôle du DBA est de s'occuper de tout ce qui est technique, entre autre des performances, de la maintenance, les partitions, les bugs ...

Lorsque je modélise, je pense déjà à l'indexation.

La modélisation répond à un besoin fonctionnel et non technique. Je pense que vous mélangez ces deux notions.

J'essaie d'éviter les index inutiles et j'imagine déjà quels seront ceux pertinents à ajouter (notamment les multi-colonnes).

Ce n'est pas le rôle de la modélisation de penser à des aspects techniques.
Les bouquins que j'ai sur merise parlent que des aspects fonctionnelles et n'abordent aucun SGBD en particulier.

Votre exemple est en effet plus parlant.

Vous voulez dire d'un aspect bien plus technique touchant des milliers de personnes en France.

Je pense que vous mélangez les aspects fonctionnels d'avec les aspects techniques.
En ce qui me concerne, je me suis toujours occupé des aspects techniques car l'utilisateur demande de la performance, en plus de son besoin fonctionnel.
Sinon à quoi peut servir une base de données bien modélisée si les accès sont hyper long ?

Si la modélisation permet de bien concevoir votre base de données, ce n'est pas elle qui va résoudre tous vos problèmes de performances.
Entre autre :
--> les goulots d'étranglements duent au trafic réseau,
--> au nombre d'utilisateurs en parallèle sur une machine,
--> la taille mémoire que le serveur dispose,
--> le paramétrage du SGBD (sérialisation des accès, taille des buffers),
--> du découpage des tables (partitions),
--> de la rapidité des disques durs,
--> de la répartition des partitions sur plusieurs disques afin d'améliorer la rapidité des accès,
--> de la réplications,
--> de la pertinence des index,
--> de la bonne écriture des requêtes,
--> de savoir appliquer correctement le plan d'exécution des requêtes,
--> de réorganiser les tables fréquemment afin de conserver
--> de la reprise en cas de plantage,
--> de la disponibilité du serveur 24H/24H.

C'est un métier (DBA) et cela se fait tous les jours et non pas la modélisation qui se fait en début de projet, et où l'on ne revient plus dessus.
Et une base de données, ça vie, et il arrive parfois qu'il faut changer quelques règles duent à de nouvelles fonctionnalités non prévues au départ, lors de sa conception.

Donc arrêter de dire que tout ce fait dans la modélisation et qu'il le DBA ne fait strictement rien.

@+

[CinePhil]

Et si on arrêtait cette bagarre stérile et inutile dans une discussion marquée résolue ?

[Artemus24]

Salut scamphp.

Voila pourquoi c'est compliqué pour un débutant en auto-formation... car personne n'est jamais d'accord sur rien lol

C'est normal car derrière une base de données se cache plusieurs métiers différents.
En ce qui me concerne, je ne m'occupe pas de la modélisation mais plus des aspects systèmes, techniques et performance.

Il faut commencer par le début, à savoir comprendre la fonctionnelle de votre projet.
Ensuite, faire de la modélisation (avec un crayon et du papier).
Puis utiliser un outil qui va vous créer votre modèle conceptuel des données (MCD).
Ensuite passer au modèle logique des données (MLD), autrement dit le choix du SGBD et l'écriture (Data Definition Language) de votre base de données.
Les rêquetes sont faites pour manipuler vos données ( Data Manipulation Language).
Et il y a aussi le modèle conceptuel des traitements, où l'on s'intéresse aux requêtes et aux performances.
Et enfin la maintenance.

Je reconnais que nous nous sommes écartés du sujet initiale.
Pour répondre à nouveau, il faut éviter d'avoir trop de colonnes dans une table.
Evitez d'avoir une longueur de ligne qui dépasse la taille de la page, à savoir 16K (innodb-page-size = 16K).

Et de bien respecter la modélisation qui ne comprend pas que le MCD.
Je ne sais pas pourquoi, tout le monde s'arrête au MCD et oublie très fréquement le MCT.

C'est la notion de poids d'une colonne ne servant pas à une recherche.

Cette notion est secondaire si la ligne rentre entièrement dans la page.
Sachez que l'on peut mettre plusieurs lignes dans une page et de ce fait vous avez deux notions, à savoir :
--> la lecture physique (donc de la page),
--> la lecture logique (donc de la ligne),
la première lecture est un accès au disque dur et est très très long.
la seconde lecture se fait en mémoire, c'est-à-dire dans la page stockée en mémoire et est très rapide.

Si votre ligne est à cheval sur deux pages, ce qui peut parfois arriver, vos accès seront donc deux fois plus long que si la ligne est dans une seule page.
Et dans ce cas, la lecture logique et la lecture physique seront identiques.
Inversement, si plusieurs lignes sont dans la même page, par exemple 10 lignes par pages, une lecture physique va correspondre à 10 lectures logiques.
Autrement dit, vos accès seront bien plus rapide.

Hormi cet aspect technique, quand vous faites une clause where dans une requête, les colonnes doivent être indexés. Pourquoi ?
Sans index, le SGBD doit parcourir toutes les lignes de la table avant de trouver la bonne ligne.
Avec un index, il parcourt d'abord celui-ci pour trouver l'adresse physique sur le disque de la page et va ensuite lire physiquement la page.
A votre avis, quel est l'approche la plus performance, lire les pages physiques jusqu'à trouver la bone ligne ou bien parcourir l'index et lire physiquement 1 seule page ?

Ensuite, il y a une façon d'écrire vos requêtes qui ont une influence sur la performance. Voir ce que dit Escartefigue un peu plus bas dans ce sujet.

@+

[scamphp]

Evitez d'avoir une longueur de ligne qui dépasse la taille de la page, à savoir 16K (innodb-page-size = 16K).

Je suis désolé après avoir fait une formation sur PHP je pensais que Mysql était un accessoire mais je me rend compte que c'est vraiment quelque chose de primordial et que je vais devoir y consacrer au tant de temps qu'à PHP.


* La taille de la page ??? c'est quoi une page, c'est le synonyme de table...

* 16k c'est 16ko... n'importe quel contenu texte d'un article fait plus de 16ko

Je suis désolé d'avoir lancé un sujet qui me dépasse

Après je marquerais Résolu pour faire plaisir CinePhil, dont l’obsession est de clore les sujets

[CinePhil]

Je suis désolé après avoir fait une formation sur PHP je pensais que Mysql était un accessoire mais je me rend compte que c'est vraiment quelque chose de primordial et que je vais devoir y consacrer au tant de temps qu'à PHP.

MySQL est un système de gestion de bases de données (SGBD) et PHP est un langage de programmation. Ce sont eux choses très différentes.
Une base de données MySQL peut être utilisée par un programme développé en PHP ou n'importe quel autre langage moderne (Java, Python, C#...).

Il existe d'autres SGBD, généralement plus complets et plus performants que MySQL, tels que PostgreSQL, SQL Server, Oracle...

* La taille de la page ??? c'est quoi une page, c'est le synonyme de table...

Pour faire vite, c'est une unité d'espace disque lisible en une seule fois par le SGBD. Si une ligne de la table occupe plus de 16 ko et que la taille de la page est de 16 ko, il faudra plus d'une lecture pour lire cette ligne.

* 16k c'est 16ko... n'importe quel contenu texte d'un article fait plus de 16ko

En considérant qu'un caractère ou un entier simple est codé sur 4 octets, on peut quand même stocker 4000 caractères ou entiers dans 16 ko (c'est pas tout à fait juste mais là aussi c'est pour faire vite)

Je suis désolé d'avoir lancé un sujet qui me dépasse

C'est bien de s'intéresser aux bonnes pratiques en matière de BDD avant de se lancer tête baissée dans la réalisation de sa BDD en n'ayant que des connaissances (plus ou moins bonnes) de développeur de programmes.

Après je marquerais Résolu pour faire plaisir CinePhil, dont l’obsession est de clore les sujets

La discussion est déjà marquée résolue !
Sans doute parce que votre question initiale a déjà obtenue sa réponse.

[scamphp]

En considérant qu'un caractère ou un entier simple est codé sur 4 octets, on peut quand même stocker 4000 caractères ou entiers dans 16 ko (c'est pas tout à fait juste mais là aussi c'est pour faire vite)

Voici ma nouvelle interrogation ou déduction...

Dans un autre sujet pour ne pas me faire engueuler par Cinephil

https://www.developpez.net/forums/d1.../#post10277653

[Artemus24]

Salut à tous.

Je suis désolé après avoir fait une formation sur PHP je pensais que Mysql était un accessoire

La gestion des accès à votre base de données se fait au travers du SGBDR qui se nomme MySql.
Dans le même genre, vous avez apache qui est destiné à gérer les accès à votre site web.
Et non, ce ne sont pas des accessoires mais des serveurs !

je me rends compte que c'est vraiment quelque chose de primordial et que je vais devoir y consacrer au tant de temps qu'à PHP.

Sans Apache et sans MySql, vous ne pouvez pas créer des sites web qui sont accessibles depuis l'internet.

La taille de la page ??? c'est quoi une page, c'est le synonyme de table...

C'est l'unité de base de la lecture physique sous MySql.
C'est en gros, un ensemble de pistes sur votre disque dur.

16k c'est 16ko... n'importe quel contenu texte d'un article fait plus de 16ko

Qu'est-ce que vous voulez que ça soit d'autre ? Ce sont bien des kilo octets, soit 1k = 1024 octets.
Oui, voire même beaucoup plus.

Je suis désolé d'avoir lancé un sujet qui me dépasse

Ne soyez pas désolé. Ce que vous devez faire, c'est acheter un bon bouquin sur MySql et de faire des exercices.
Et quand vous ne savez pas, et bien posez la question dans ce forum, consacré à MySql.

@+