Quelles sont les causes de la table MySQL pour être corrompu?

Salut

Ive été googler pendant un moment et im ne reçois aucune réponses claires

Quelles sont toutes les causes possibles de tableaux currupt dans une base MySQL? Particulièrement pour les tables InnoDB

Peuvent exécuter tout type d'insert / update / delete corruption cause de requêtes?
Tout lire IVE suggère que la corruption est due au niveau du serveur, comme l'hôte faisant des mises à niveau ou le serveur de s'écraser.

Quel format de table est mieux / plus fiables et pourquoi; InnoDB ou MyISAM

Vous voudrez peut-être Google "SQL Injection".

Aussi, être plus précis sur ce que vous entendez par "corruption". De toute évidence, l'exécution d'un insert / update / delete commande pourrait le rate si elle se fait mal.

Mais comment se fait une injection Sql faire une table de «corrompu», pouvez-vous penser à un exemple de quelque chose qui pourrait provoquer cette erreur à afficher dans PHP My Admin?

"Information erronnée dans le fichier:".... (nom du fichier...)

Vous ne pouvez pas faire table réparation ou rien. Les données sont plus tout simplement. Il a seulement affecté des tables InnoDB.

La documentation de MySQL contient une section intéressante sur ce qui peut provoquer une table MyISAM pour être corrompues:

http://dev.mysql.com/doc/refman/5.1/en/ ... ables.html

Rien sur InnoDB?

Crap, n'a même pas voir la partie InnoDB de votre question, désolé!

Pas de soucis; devine qu'il sera à jamais un mystère. Ive de lire que InnoDB est le mieux pour les «transactions» et MyISAM est pour "non-transactions», peut-on expliquer la différence?

Transaction InnoDBs-vaisselle.

Cela signifie que l'intégrité des données ne sera pas compromise au long de votre processus de requête.

Et cela signifie que vous pouvez utiliser de commencer la transaction et le démantèlement / commit (transactions SQL)

Et cela signifie que vous pouvez exécuter une série de requêtes, les captures d'exceptions que vous le souhaitez, et restaurer vos modifications base de données si besoin est. Pensez-y comme relecture vos modifications - vous aligner un tas de requêtes, vous les exécuter, et puis si vous n'aviez pas de hoquets, puis vous «engager», ainsi que tous les changements prennent place. Sinon, vous "démantèlement" et aucune des requêtes auront une incidence sur votre table.

MyISAM utilise les opérations atomiques - tout le contraire. Lorsque le dommage est fait, alors son fait. Son un peu plus old-school et de sa pensée par certains comme un peu plus vite (même si ces jours thats un point très discutable). < br>
(Wasnt sûr de votre niveau de connaissance est, donc j'ai essayé de l'enfoncer dans toutes les formules que vous verrez probablement discutés, mais aussi essayé de le rendre compréhensible, trop Si vous voulez lire un peu plus sur les différences, alors vous pouvez jeter un oeil par ici . Si vous voulez lire sur les transactions SQL, theres un tutoriel décent ici . )

Oui, mais ce qui se passe si le serveur ou la machine ne le bas pendant une opération de validation?

Merci d'UPS qui second lien est vraiment instructif. Ive jamais eu besoin de faire une «transaction», mais je peux voir les avantages.

Savez-vous si sa possible que pour une requête mauvaise sortes pourrait causer des problèmes avec la table de fichier physique sur le serveur, une erreur de rendu comme ça dans phpmyadmin:

"Information erronnée dans le fichier:".... (nom du fichier...)

D'après ce que IVE lire sur différents sites c'est quelque chose au niveau du serveur (ex.: un crash serveur ou une mise à niveau ne se fait pas correctement), vous êtes en désaccord? Cette tables InnoDB et non pas seulement affecté myisam (qui étaient seulement en format MyISAM pour la fonctionnalité du texte intégral).

Thats un échec de durabilité. Bien que, pour que cela se produise le pouvoir aurait pour sortir exactement au bon moment (les données restent cohérents et isolées, donc son tout ou rien). Crash Recovery est utile, mais je suppose que si étaient pointilleux, vous ne pouvez pas faire confiance à 100% non plus. Au pire, vous perdez cette opération, mais d'un autre côté, vous n'avez pas à écrire quoi que ce soit partiellement, donc vous devriez rester dans un état utilisable. Respect ACIDE s'occupe d'une quantité énorme d'inquiétude, mais si regardions les. 0000001%, alors vous avez les meilleures sauvegardes.

dire quelque chose avec l'équipement accueille les?

Vous voulez dire une requête qui est fait quand un accident s'est produit? Peux pas imaginer que cela soit le cas peu probable que ses toutes les tables ont été interrogée dans le même temps.

Don't buy-in pour que le dernier message trop - genre Spork viré de moi dans le terrier du lapin, mais mal les expliquer anywho.

Les tables InnoDB sont l'acide-compatibles, ce qui leur confère leur capacité d'opération. ACIDE signifie atomicité, Cohérence, Isolation et Durabilité. Wikipedia fait un bien meilleur travail que je ne le peut sans doute, mais thats où la durabilité entre en jeu.

S'agissant du calendrier, il wouldnt être pendant que la requête est en cours d'exécution - ce serait commettre au cours de la procédure. L'heure exacte précise dans l'exemple sporks serait pendant toute mysql emplois internes sont causés par le Comité qui persiste enfin les modifications aux tableaux.

Ne travaille donc avec une table InnoDB dire sa une transaction, même si vous n'y allez pas
BEGIN

INSERT, etc

COMMIT
Im un peu perplexe maintenant, si InnoDB sont transaction "sûr" et theyre les seuls à être perdus (par opposition aux tables MyISAM) dans un accident ou d'échec...: 0
peut-être son tout simplement partie du débat sur le choix MyISAM ou InnoDB?
Merci pour toutes ces infos i tho appris de nouvelles choses.

Tous les trucs de transaction est vraiment une question de choix personnel et, comme vous l'avez suggéré, une fonctionnalité permettant de débat sur le moment de décider lequel utiliser. C'est probablement pas lié à la corruption youve expérimentés. Je ne vois pas beaucoup là-bas, mais le fichier qui ne l'erreur spécifier? Le fichier FRM comme celui-ci ? Aucune façon à ce sujet, la reprise semble être le mieux à vos AFAICT pari.