Mysql
 sql >> Base de données >  >> RDS >> Mysql

Puis-je configurer Mysql pour partitionner automatiquement ?

(Cette réponse est dirigée vers le schéma et SELECT.)

Puisque vous anticipez des millions de lignes, je veux d'abord souligner quelques améliorations au schéma.

  • FLOAT(m,n) est généralement la « mauvaise » chose à faire car elle conduit à deux arrondis. Utilisez simplement FLOAT (ce qui semble "juste" pour des métriques comme la tension) ou utilisez DECIMAL(m,n) . FLOAT est de 4 octets ; dans les cas donnés, DECIMAL serait de 3 ou 4 octets.

  • Lorsque vous avez les deux INDEX(a) et INDEX(a,b) , le premier n'est pas nécessaire puisque le second peut le couvrir. Vous avez 3 clés inutiles. Cela ralentit les INSERTs .

  • INT(3) -- Dites-vous un "numéro à 3 chiffres" ? Si c'est le cas, considérez TINYINT UNSIGNED (valeurs 0..255) pour 1 octet au lieu de INT pour 4 octets. Cela permettra d'économiser de nombreux Mo d'espace disque, donc de vitesse. (Voir aussi SMALLINT , etc, et SIGNED ou UNSIGNED .)

  • Si filename se répète beaucoup, vous voudrez peut-être le "normaliser". Cela permettrait d'économiser de nombreux Mo.

  • Utilisez NOT NULL sauf si vous avez besoin de NULL pour quelque chose.

  • AUTO_INCREMENT=690892041 implique que vous êtes à environ 1/3 du chemin vers le désastre avec id , qui plafonnera à environ 2 milliards. Utilisez-vous id pour rien? Se débarrasser de la colonne éviterait le problème ; et changez la UNIQUE KEY à PRIMARY KEY . (Si vous avez besoin de id , parlons plus loin.)

  • ENGINE=MyISAM -- Le changement a des ramifications, à la fois favorables et défavorables. La table deviendrait 2 à 3 fois plus grande. Le "bon" choix de PRIMARY KEY accélérerait encore cela SELECT significativement. (Et peut ou non ralentir d'autres SELECTs .)

Une note sur le SELECT :Depuis string et unit_num sont des constantes dans la requête, les deux derniers champs de ORDER BY timestamp asc, string asc, unit_num asc sont inutiles. S'ils sont pertinents pour des raisons non apparentes dans le SELECT , mes conseils sont peut-être incomplets.

Ceci

WHERE filename = 'foobar'
  AND unit_num='40'
  AND string='2' 
  AND timestamp >= ...

est géré de manière optimale par INDEX(filename, unit_name, string, timestamp) . L'ordre des colonnes n'est pas important sauf cet timestamp doit être dernier . Réorganiser l'actuel UNIQUE clé, vous vous donnez l'indice optimal. (Pendant ce temps, aucun des index n'est très bon pour ce SELECT .) En faire la PRIMARY KEY et la table InnoDB le rendrait encore plus rapide.

Partitionnement ? Aucun avantage. Pas pour les performances ; pas pour tout ce que vous avez mentionné. Une utilisation courante du partitionnement consiste à purger « l'ancien ». Si vous avez l'intention de le faire, parlons plus loin.

Dans les grandes tables, il est préférable de regarder tous les SELECTs importants simultanément afin de ne pas accélérer l'un tout en démolissant la vitesse des autres. Il peut il s'avère même que le partitionnement aide dans ce genre de compromis.