Fassen Sie die grundlegendsten Vorgänge der MySQL-Optimierung zusammen

                                                                                                               

Optimierungsideen

Die detaillierten MySQL-Optimierungsschritte lauten wie folgt:

• Überprüfen Sie die Datentabellenstruktur und verbessern Sie das unvollständige Design.
• Führen Sie das Hauptgeschäft aus und sammeln Sie häufig verwendete Datenbankabfragen SQL.
• Analysieren Sie die Abfrage-SQL und Teilen Sie es entsprechend auf. Fügen Sie Indizes und andere Optimierungsabfragen hinzu.
• Optimieren Sie beim Optimieren von SQL die Codelogik.
• Fügen Sie lokalen Cache und Redis-Cache hinzu. Versuchen Sie, keine NULL-Werte zu verwenden Legen Sie keinen Standardwert für den erstellten Wert fest. MySQL setzt den Standardwert auf NULL. Warum ist es also nicht gut, NULL zu verwenden?

NULL macht die Indexpflege komplizierter. Es wird dringend empfohlen, NOT NULL für Indexspalten festzulegen NOT IN, != und andere negative bedingte Abfragen geben immer leere Ergebnisse zurück, wenn ein <code>NULL-Wert vorhanden ist. Die Abfrage ist fehleranfällig

Die Spalte NULL erfordert einen Zusätzliches Byte, um festzustellen, ob bei Verwendung von NULL für das Flag-Bit NULL。那么为啥用NULL不好呢？

• NULL使得索引维护更加复杂，强烈建议对索引列设置NOT NULL
• NOT IN、!=等负向条件查询在有NULL值的情况下返回永远为空结果，查询容易出错
• NULL列需要一个额外字节作为判断是否为NULL的标志位
• 使用NULL时和该列其他的值可能不是同种类型，导致问题。（在不同的语言中表现不一样）
• MySQL难以优化对可为NULL的列的查询

所以对于那些以前偷懒的字段，手动设置一个默认值吧，空字符串呀，0呀补上。

虽然这种方法对于MySQL的性能来说没有提升多少，但是这是一个好习惯，而且以小见大，不要忽略这些细节。

添加索引

对于经常查询的字段，请加上索引，有索引和没有索引的查询速度相差十倍甚至更多。

• 一般来说，每张表都需要有一个主键id字段
• 常用于查询的字段应该设置索引
• varchar类型的字段，在建立索引的时候，最好指定长度
• 查询有多个条件时，优先使用具有索引的条件
• 像LIKE条件这样的模糊搜索对于字段索引是无效的，需要另外建立关键词索引来解决
• 请尽量不要在数据库层面约束表和表之间的关系，这些表之间的依赖应该在代码层面去解决

当表和表之间有约束时，虽然增删查的SQL语句变简单了，但是带来的负面效果是插入等操作数据库都会去检查约束（虽然可以手动设置忽略约束），这样相当于把一些业务逻辑写到了数据库层，不便于维护。

优化表字段结构

数据库中那些可以用整形表示的数据就不要使用字符串类型，到底是用varchar还是char要看字段的可能值。

这种优化往往在数据库中有大量数据以后是不可行的，最好在数据库设计之前就设计好。

• 对于那些可能值很有限的列，使用tinyint代替VARCHAR，
  • 比如记录移动设备平台，只有两个值：android，ios，那么就可以使用0表示android，1表示ios，这种列一定要写好注释
  • 为什么不用ENUM呢？ENUM扩展困难，比如后来移动平台又增加了一个ipad，那岂不是懵逼了，而tinyint加个2就行，而且ENUM在代码里面处理起来特别奇怪，是当成整形呢还是字符串，各个语言不一样。
  • 这种方式，一定要在数据库注释或者代码里面写明各个值的含义
• 对于那些定长字符串，可以使用char，比如邮编，总是5位
• 对于那些长度未知的字符串，使用varchar
• 不要滥用bigint，比如记录文章数目的表id字段，用int就行了，21亿篇文章上限够了
• 适当打破数据库范式添加冗余字段，避免查询时的表连接

查询的时候，肯定int类型比varchar

von NULL es möglicherweise nicht vom gleichen Typ wie andere Werte in der Spalte ist, was zu Problemen führen kann . (Es verhält sich in verschiedenen Sprachen unterschiedlich.)

MySQL hat Schwierigkeiten, Abfragen für Spalten zu optimieren, die NULL sein können. 🎜🎜🎜Legen Sie daher für die zuvor faulen Felder manuell einen Standardwert fest, den Nullzeichen-String , addiere 0. 🎜🎜Obwohl diese Methode die Leistung von MySQL nicht wesentlich verbessert, ist sie eine gute Angewohnheit, und kleine Dinge bewirken große Dinge, also ignorieren Sie diese Details nicht. 🎜🎜🎜🎜Index hinzufügen🎜🎜Für häufig abgefragte Felder fügen Sie bitte Indizes hinzu. Die Abfragegeschwindigkeit mit und ohne Indizes unterscheidet sich um das Zehnfache oder mehr. 🎜🎜🎜Im Allgemeinen muss jede Tabelle über ein Primärschlüssel-id-Feld verfügen. 🎜🎜Felder, die häufig für Abfragen verwendet werden, sollten indiziert werden. 🎜🎜Felder vom Typ varchar werden bei der Erstellung und Indizierung indiziert Geben Sie am besten die Länge an. 🎜🎜Wenn die Abfrage mehrere Bedingungen hat, werden die Bedingungen mit Indizes bevorzugt. 🎜🎜Fuzzy-Suchen wie LIKE-Bedingungen sind für Feldindizes ungültig und es müssen zusätzliche Schlüssel eingerichtet werden Zu lösender Wortindex🎜🎜Bitte versuchen Sie, die Beziehung zwischen Tabellen auf Datenbankebene nicht einzuschränken. Die Abhängigkeiten zwischen diesen Tabellen sollten auf Codeebene aufgelöst werden🎜🎜🎜Wenn ein Problem zwischen Tabellen auftritt Einschränkung: Obwohl die SQL-Anweisungen zum Hinzufügen, Löschen und Abfragen einfacher werden, besteht der negative Effekt darin, dass die Datenbank die Einschränkungen für Vorgänge wie das Einfügen überprüft (obwohl die Einschränkungen manuell so festgelegt werden können, dass sie ignoriert werden), was dem Schreiben einiger Einschränkungen entspricht Geschäftslogik auf die Datenbankebene übertragen. Einfach zu warten. 🎜🎜🎜🎜Optimieren Sie die Tabellenfeldstruktur🎜🎜Verwenden Sie keine Zeichenfolgentypen für Daten in der Datenbank, die durch Ganzzahlen dargestellt werden können. Ob varchar oder char verwendet werden soll, hängt davon ab auf dem Feld möglicher Wert. 🎜🎜Diese Art der Optimierung ist oft nicht möglich, wenn die Datenbank eine große Datenmenge enthält. Es ist am besten, sie vor dem Datenbankdesign zu entwerfen. 🎜🎜🎜Für Spalten mit sehr begrenzten möglichen Werten verwenden Sie tinyint anstelle von VARCHAR 🎜🎜Um beispielsweise die Plattform für mobile Geräte aufzuzeichnen, gibt es nur zwei Werte: android, ios, then Sie können 0 verwenden, um Android darzustellen, und 1, um iOS darzustellen. Diese Art von Spalte muss gut kommentiert sein🎜🎜Warum nicht ENUM verwenden? ENUM lässt sich beispielsweise nur schwer erweitern. Wäre das nicht verwirrend? a 2, und ENUM ist im Code sehr seltsam zu handhaben. Ob es als Ganzzahl oder als Zeichenfolge behandelt wird, variiert von Sprache zu Sprache. 🎜🎜Bei dieser Methode muss die Bedeutung jedes Werts in den Datenbankkommentar oder -code geschrieben werden🎜🎜🎜🎜Für diese Zeichenfolgen fester Länge können Sie char verwenden, z. B. Postleitzahl immer 5 Ziffern🎜 🎜Verwenden Sie für Zeichenfolgen mit unbekannter Länge varchar🎜🎜Missbrauchen Sie bigint nicht, wie z. B. das Tabellenfeld id Zeichnet die Anzahl der Artikel auf, int reicht aus, die Obergrenze von 2,1 Milliarden Artikeln reicht aus🎜🎜Brechen Sie das Datenbankparadigma ordnungsgemäß und fügen Sie redundante Felder hinzu, um Tabellenverbindungen bei Abfragen zu vermeiden🎜🎜🎜Beim Abfragen Stellen Sie sicher, dass Sie den Typ int verwenden. Er ist schneller als varchar, da der Vergleich von Ganzzahlen durch direkten Aufruf des zugrunde liegenden Operators erreicht werden kann, während der Vergleich von Zeichenfolgen zeichen- zeichenweiser Vergleich. 🎜🎜Die Abfrage von Daten fester Länge ist schneller als die Abfrage von Daten variabler Länge, da der Versatz zwischen Daten fester Länge und Daten fest ist und es einfach ist, den Versatz der nächsten Daten zu berechnen. Bei Daten variabler Länge ist ein weiterer Schritt erforderlich, um den Offset der nächsten Daten abzufragen. Aber. Daten mit fester Länge verschwenden möglicherweise mehr Speicherplatz. 🎜

Aufteilung großer Tabellen

Stellen Sie bei Tabellen, deren Datenvolumen in naher Zukunft 5 Millionen überschreiten oder schnell wachsen könnte, sicher, dass die Tabellen im Voraus vertikal oder horizontal aufgeteilt werden. Wenn das Datenvolumen eine Million überschreitet, erhöht sich die Abfragegeschwindigkeit offensichtlicher Rückgang.

Versuchen Sie, den Plan für die Unterdatenbank und die Untertabelle in der frühen Phase des Datenbankentwurfs fertigzustellen, da sonst die Codekomplexität erheblich zunimmt und es später schwierig ist, sie zu ändern.

Die vertikale Tabellenpartitionierung basiert auf externen Variablen wie Datumsangaben, und die horizontale Tabellenpartitionierung basiert auf bestimmten Feldbeziehungen in der Tabelle, wobei die Tabelle mithilfe einer Hash-Zuordnung in gleiche Teile unterteilt wird.

Voraussetzung für Unterdatenbank und Tabellenunterdatenbank ist, dass Sie vor der Ausführung der Abfrageanweisung bereits wissen, in welche Unterdatenbank und welche Untertabelle die abzufragenden Daten fallen dürfen.

Abfrageanweisungen optimieren

Dies ist der Auslöser vieler Systemdatenbankengpässe.

• Bitte versuchen Sie, einfache Abfragen zu verwenden und Tabellenverknüpfungen zu vermeiden.
• Bitte vermeiden Sie vollständige Tabellenscans, unter anderem:
  • Die Bedingung der Where-Klausel ist immer wahr oder leer
  • Verwenden Sie LIKE. LIKE
  • 使用不等操作符（<>、!=）
  • 查询含有is null的列
  • 在非索引列上使用or
  Verwenden Sie Ungleichheitsoperatoren (<>, !=).
• Bei Abfragen mit mehreren Bedingungen stellen Sie bitte einfache Abfragebedingungen oder Indexspaltenabfragen voran.
• Bitte versuchen Sie, die Spalten anzugeben, die Sie abfragen müssen. Seien Sie nicht faul und verwenden Sie select *
  • If Wenn Sie es nicht angeben, werden einerseits redundante Daten, belegte Bandbreite usw. zurückgegeben.
  • Wenn andererseits MySQL eine Abfrage ausführt und keine Felder vorhanden sind, werden zunächst die Felder in der Tabelle abgefragt Struktur
• Die Abfrageschlüsselwörter in Großbuchstaben sind etwas schneller als die in Kleinbuchstaben
• Die Verwendung von Unterabfragen wird das Erstellen einer temporären Tabelle etwas langsamer machen als JOIN und UNION
• Versuchen Sie, beim Abfragen von Indexfeldern keine Datenbankfunktionen zu verwenden Es ist unpraktisch, Abfrageergebnisse zwischenzuspeichern.
• Wenn Sie nur eine Datenzeile benötigen, verwenden Sie bitte LIMIT 1. Wenn die Daten zu viele sind, legen Sie bitte LIMIT entsprechend fest, Paging-Abfrage.
• Bestellen Sie niemals ORDER BY RAND (), da die Leistung extrem ist niedrig

Cache hinzufügen

Verwenden Sie Redis und andere Caches sowie lokalen Dateicache usw., was die Anzahl der Datenbankabfragen erheblich reduzieren kann. Beim Caching müssen Sie die Dateneigenschaften Ihres eigenen Systems analysieren und entsprechende Entscheidungen treffen.

• Einige häufig verwendete Daten, wie z. B. Konfigurationsinformationen usw., können im Cache abgelegt werden.
• Die Tabellenstruktur der Datenbank kann lokal zwischengespeichert werden.
• Die zwischengespeicherten Daten müssen rechtzeitig aktualisiert werden Es muss ein Zeitraum festgelegt werden.
• Um die Systemkomplexität zu erhöhen, achten Sie unbedingt auf Kompromisse.

Überprüfen Sie die Datentabellenstruktur. Empfohlenes Lernen: „

MySQL-Video-Tutorial.“ „

Das obige ist der detaillierte Inhalt vonFassen Sie die grundlegendsten Vorgänge der MySQL-Optimierung zusammen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!