![\"twitter\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/twitter.png\" "\\"Share")
<\/a><\/a>![\"linkedin\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/linkedin.png\" "\\"Share")
<\/a>![\"mail\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/mail.png\" "\\"Share")
<\/a>Il n’y a pas de question b\u00eate…<\/p>\n
<\/p>\n
Il n’est pas rare d’entendre cette question concernant la taille d’une table (ou d’une base). \u00a0“La table est-elle trop grosse ?”<\/p>\n
<\/p>\n
Pourquoi se poser la question ?<\/p>\n
Il n’existe pas de taille maximale d’une table, en terme de ligne ou d’espace de stockage.<\/p>\n
D’apr\u00e8s le document des limitations de SQL Server 2016<\/a>\u00a0:<\/p>\n Une table est donc limit\u00e9e \u00e0 511 Petaoctets (511 millions de Gigaoctets). Concr\u00e8tement, la seule limite aujourd’hui d’une table est l’espace disque total qui peut \u00eatre allou\u00e9 \u00e0 la machine qui h\u00e9berge la base…<\/p>\n Nombre de lignes<\/strong><\/p>\n Les principales op\u00e9rations effectu\u00e9es sur une table ( recherche de valeurs, jointure entre deux tables, tri des donn\u00e9es, \u00e9limination des doublons) d\u00e9pendent clairement du nombre de lignes de la table.<\/p>\n Par exemple, s’il faut une microseconde pour v\u00e9rifier que la valeur d’une colonne correspond \u00e0 une constante (WHERE colonne = ‘ABC’), il faudra une seconde pour v\u00e9rifier cette valeur sur un million de lignes, et 100 secondes pour cette m\u00eame op\u00e9ration sur 100 millions de lignes.<\/p>\n Volume de donn\u00e9es<\/strong><\/p>\n Lorsqu’il s’agit de manipuler les donn\u00e9es, le temps de traitement d\u00e9pend aussi clairement du volume de ces donn\u00e9es. Balayer 100Go de donn\u00e9es sera dans l’absolu 100 fois plus long que balayer 1Go de donn\u00e9es.<\/p>\n La volum\u00e9trie totale d\u00e9pend bien entendu de la taille d’une ligne. Une table de 100 millions de petites lignes (quelques colonnes de type entier, par exemple) pourra \u00eatre bien moins volumineuse qu’une table de 1 millions de grosses lignes (plusieurs colonnes de type Text par exemple).<\/p>\n <\/p>\n Donc, dans l’absolu, plus la table est “grosse”, en nombre de lignes et\/ou en volum\u00e9trie totale, plus les traitements qui l’utilisent sont susceptibles de durer longtemps.<\/p>\n Fort heureusement, SQL Server dispose de nombreux moyens pour r\u00e9duire les donn\u00e9es brass\u00e9es, et donc les temps de traitement. Les deux principaux sont les suivants:<\/p>\n Cache des pages en m\u00e9moire<\/strong><\/p>\n Lorsqu’une page de donn\u00e9es est lue depuis le disque, SQL Server va maintenir en m\u00e9moire une image de cette aussi longtemps que possible. Les lectures ult\u00e9rieures de cette m\u00eame page seront infiniment plus rapides.<\/p>\n Indexes<\/strong><\/p>\n Le but principal de l’indexe est d’acc\u00e9l\u00e9rer \u00a0l’acc\u00e8s aux donn\u00e9es. Sans entrer dans les d\u00e9tails (par exemple disponibles ici<\/a>), l’indexe permet de r\u00e9duire consid\u00e9rablement le nombre de pages lues lors de recherche et de jointure impliquant la table. Une table disposant d’indexes pertinents (c-\u00e0-d d’indexes qui vont permettre d\u2019acc\u00e9l\u00e9rer les requ\u00eates les plus couramment ex\u00e9cut\u00e9es) ne devrait donc pas subir les probl\u00e8mes \u00e9voqu\u00e9es ci-dessus, m\u00eame lorsque sa volum\u00e9trie devient importante.<\/p>\n Et il existe bien entendu un grand nombre de moyens suppl\u00e9mentaires qui permettront de g\u00e9rer une table de forte volum\u00e9trie: partitionnement, purge r\u00e9guli\u00e8re de donn\u00e9es, historisation de donn\u00e9es dans des tables d’archive, compression de donn\u00e9es, …<\/p>\n <\/p>\n En conclusion, on peut dire qu’une table qui ne disposerait pas d’indexe pertinent ET qui ne pourrait b\u00e9n\u00e9ficier du m\u00e9canisme de cache des donn\u00e9es (parce qu’elle ne peut \u00eatre int\u00e9gralement stock\u00e9e en m\u00e9moire, par exemple) \u00a0pourrait poser des probl\u00e8mes de performance lorsque sa taille devient “importante”. D\u00e8s que la volum\u00e9trie d\u00e9passe les quelques gigaoctets, les probl\u00e8mes peuvent survenir. Mais cela signifie simplement qu’il est temps de s’int\u00e9resser \u00e0 l’indexation de la table…<\/strong><\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n Il n’y a pas de question b\u00eate… Il n’est pas rare d’entendre cette question concernant la taille d’une table (ou d’une base). \u00a0“La table est-elle trop grosse ?” Pourquoi se poser la question ? Taille maximale d’un objet… Continuer la lecture \n
Consid\u00e9rations de performance.<\/strong><\/h2>\n
<\/a><\/a><\/a>","protected":false},"excerpt":{"rendered":"