fred078

Bonjour, Simplement pour vous tenir au courant, nous avons finalement choisi de scinder notre table en plusieurs table. Cela a résolu nos problèmes. Merci pour vos conseils.

Bonjour, Je n'ai pas essayé sous ssh. Je vais me pencher dessus.

Non, jamais de recherches globales parmi tous les clients, les recherches se font que pour les informations d'un même client (hors dans le cas d'un partitionnement alphabétiques les données d'un seul et même client seront toujours dans la même table). Mais bon, si vous me déconseillez aussi nettement cette méthode je vais vous suivre et faire quelques tests de jointures pour voir ce que ça donne.

_AT_captain_torche : Oui, ce sont des infos supplémentaires nécessaire suite à l'évolution de certaines fonctionnalités. En fait cette table est composée de 2 "gros" champs contenant 99% du volume, et une 15ène d'autres "petits" champs. J'ai testé les jointures il y a quelques temps mais j'ai été confronté à de nombreux problèmes de performances. Donc, même si notre infra à beaucoup évolué depuis (et que les structures de nos tables ont été optimisées via des INDEX plus judicieux), j'hésite à me relancer la dedans... _AT_Arlette : Non, il ne s'agit pas de Merci Facteur, c'est pour un autre site. Mais merci pour ton compliment (comment sais-tu que je fais partie de merci facteur ? je ne pensais pas l'avoir spécifié pour être plus libre dans mes propos dans le cas où un concurrent tomberait sur mes messages.)

Au final, je pense que je vais contourner le problème en divisant cette table en plusieurs tables : clients commençant par A dans la table "matable_a", clients qui commencent par B dans la table "matable_b", etc... * 26 tables. Je penses que je vais en faire hurler quelques un mais c'est ce qui me parait le plus simple et le moins générateur de problèmes sur le long terme (multiplication du volume de données : +30% chaque année)...

A ok, j'ignorais que le "vide" était en fait une valeur (si quelqu'un d'aussi inculte que moi passe par là : http://sqlpro.developpez.com/cours/null ). je pensais que ne pas passer par NULL me simplifierais la vie mais je comprends que j'ai pris une très mauvaise habitude... Donc si je comprends bien, mes tables seront moins lourdes si a partir du moment où un champs est vide, je le met en NULL plutôt que de le laisser vide ? Je vais essayer d'ajouter ce champs en spécifiant le NULL plutôt qu'un champs vide car si je peux éviter les jointures ça m'arrange (trop de mauvais souvenirs de mauvaises performances avec les jointures...).

_AT_jcaron: En fait je la met a NOT NULL pour pouvoir faire mes tests sur champs vide (... WHERE monchamp=''). Par "pas de valeur par défaut" j'entendais, pas de : ALTER TABLE `matable` ADD `monchamps` VARCHAR(10) NOT NULL DEFAULT 'valeur'; _AT_captain_torche : Ca arrive moins de 1 fois par an, et c'est probablement une des dernieres fois que ca arrive.

Bonjour, Merci pour vos réponses Nous devons ajouter un champs suite à l'évolution de notre site, nécessité de stocker de nouvelles infos. Lors de l'ajout de ce champs, aucune valeur par défaut n'est créée : ALTER TABLE `matable` ADD `monchamp` VARCHAR(10) NOT NULL ; La solution pourrait effectivement être de créer une autre table jointe, mais j'aurais préféré ajouter ce champs dans la table existante.

Bonjour, Nous avons une table relativement grosse dans notre base de donnée mysql (600 000 enregistrements, 4.5 Go). A chaque modification de la structure de cette table (par exemple l'ajout d'un simple champ varchar), le serveur mouline et rend le site inaccessible pendant plusieurs dizaines de minutes. Y-a-t-il une méthode saine pour ajouter un champ à ce type de table, sans faire planter le serveur ? Merci d'avance pour votre aide !

Bonjour, Je souhaiterais créer sur mon serveur (dédié) un système de mapping de noms de domaines. De manière à pouvoir ensuite définir des enregistrements DNS sur divers domaines de la manière suivante : ##EXEMPLE d'enregistrement pour le domaine www.mondomaine.com www IN CNAME blabla.mondeuxiemedomaine.com. Par exemple ici je souhaites que le nom de domaine www.mondomaine.com affiche blabla.mondeuxiemedomaine.com Pour ceux qui connaissent, c'est un peu comme le propose Typepad pour avoir un nom de domaine pour son blog. Est ce que quelqu'un sait comment ca se passe derriere pour mettre en place un système de mapping de noms de domaines ? Merci d'avance pour votre aide. Fred

Bonjour, Merci pour toutes ces pistes. Nous allons les étudier une à une. Nous avons commencé par créer un index (id_1,id_2). J'ai pas l'impression que l'amélioration soit perceptible. EXPLAIN nous donne : ------------ id : 1 select_type : SIMPLE table : matable type : ref possible_keys : id_1,id_2,id_1_2 **id_1_2 correspond à l'index (id_1,id_2) key : id_1_2 key_len : 514 ref : const,const rows : 2 Extra : Using where ------------ RAM en place : 2048Mo sur chaque serveur. Beaucoup oui (INSERT et UPDATE), mais par rapport au nombre total de requetes, c'est surement pas plus de 10-15% (pour les autres questions, je vais regarder.) Par contre je viens de tomber sur quelque chose qui m'interroge : Nous retrouvons dans la page qui réalise 90% des affichages 3 requetes de ce type : SELECT champ1,champ2 FROM matable WHERE id_1='truc' AND id_2='chouette' LIMIT 1 [...] SELECT champ3,champ4 FROM matable WHERE id_1='truc' AND id_2='chouette' LIMIT 1 [...] SELECT champ5,champ6 FROM matable WHERE id_1='truc' AND id_2='chouette' LIMIT 1 Est ce que si on regroupe tout dans une seule et même requete nous aurons un gain significatif potentiel ? (ce sont des requetes séparées car certaines sortent un contenu mis en cache, d'autres non). Merci pour votre aide. Fred

Non, la recherche s'effectue sur deux champs simple type idendifiant (alphanumérique, 50 caractères max dans un varchar) c'est du genre : SELECT gros_chp_1, gros_chp_2 WHERE id_1='blabla' AND id_2='toto'

Bonjour, Il y a bien des index sur les champs recherchés, et nous avons banni les * pour toujours extraire uniquement le nécessaire.

Bonjour, Merci pour ta réponse. En fait nous avons déjà une gestion du cache pour cette table. et plusieurs serveurs avec load balancing et tout le bazar (c'est pas moi qui gère tout ca mais je sais qu'on a !) Après peut-etre qu'il y a des optimisations a faire la dessus, ils y travaillent aussi.

Bonjour, Nous avons des problèmes de lenteurs, en particulier avec les requêtes faites sur une table. Cette table a environ 500 000 enregistrements et pèse environ 3 Go (et ça va doubler/tripler dans les mois a venir). Il y a sur cette table des millions de requêtes chaque jour (requêtes PHP, table mysql). Les requêtes sont plutôt optimisées, et la table est dotée d'index. Je me pose la question suivante : Le fait de diviser cette grosse table en 26 petites tables (en divisant nos clients par ordre alphabétique : les clients dont l'identifiant commence par A auraient leurs données dans la table "table_a" par exemple) améliorerait les choses ? Pour vous donner une idée de l'architecture, cette table a peu de colonnes (une 10ene), 2 de ces colonnes contiennent de données lourdes et représentent l'essentiel du poids total de la table. Merci d'avance pour votre aide, Fred