Wie wird MySQL optimiert? Lassen Sie uns über Leistungsoptimierung aus 5 Dimensionen sprechen

Wenn der Interviewer Sie fragt: In welchen Dimensionen werden Sie die MySQL-Leistung optimieren? Wie würden Sie antworten?

Die sogenannte Performance-Optimierung zielt im Allgemeinen auf die Optimierung von MySQL-Abfragen ab. Da wir die Abfrage optimieren, müssen wir natürlich zuerst wissen, welche Links der Abfragevorgang durchläuft, und dann darüber nachdenken, welche Links optimiert werden können.

Ich verwende ein Bild, um die grundlegenden Schritte zu zeigen, die der Abfragevorgang durchlaufen muss.

Im Folgenden werden einige Strategien zur MySQL-Optimierung aus 5 Perspektiven vorgestellt.

1. Verbindungskonfigurationsoptimierung

Die Verarbeitung von Verbindungen ist der erste Schritt in der Beziehung zwischen MySQL-Client und MySQL-Server. Wenn der erste Schritt nicht gut gemacht wird, sprechen wir nicht über die folgende Geschichte.

Da die Verbindung Sache beider Parteien ist, optimieren wir sie selbstverständlich sowohl serverseitig als auch clientseitig.

1.1 Serverkonfiguration

Was der Server tun muss, ist, so viele Client-Verbindungen wie möglich zu akzeptieren. Vielleicht ist bei Ihnen der Fehler 1040: Zu viele Verbindungen aufgetreten? Das liegt daran, dass der Geist des Servers nicht breit genug ist und das Layout zu klein ist! error 1040: Too many connections的错误？就是服务端的胸怀不够宽广导致的，格局太小！

我们可以从两个方面解决连接数不够的问题：

1、增加可用连接数，修改环境变量max_connections，默认情况下服务端的最大连接数为151个

mysql> show variables like 'max_connections';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 151   |
+-----------------+-------+
1 row in set (0.01 sec)

2、及时释放不活动的连接，系统默认的客户端超时时间是28800秒（8小时），我们可以把这个值调小一点

mysql> show variables like 'wait_timeout';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wait_timeout  | 28800 |
+---------------+-------+
1 row in set (0.01 sec)

MySQL有非常多的配置参数，并且大部分参数都提供了默认值，默认值是MySQL作者经过精心设计的，完全可以满足大部分情况的需求，不建议在不清楚参数含义的情况下贸然修改。

1.2 客户端优化

客户端能做的就是尽量减少和服务端建立连接的次数，已经建立的连接能凑合用就凑合用，别每次执行个SQL语句都创建个新连接，服务端和客户端的资源都吃不消啊。

解决的方案就是使用连接池来复用连接。

常见的数据库连接池有DBCP、C3P0、阿里的Druid、Hikari，前两者用得很少了，后两者目前如日中天。

但是需要注意的是连接池并不是越大越好，比如Druid的默认最大连接池大小是8，Hikari默认最大连接池大小是10，盲目地加大连接池的大小，系统执行效率反而有可能降低。为什么？

对于每一个连接，服务端会创建一个单独的线程去处理，连接数越多，服务端创建的线程自然也就越多。而线程数超过CPU个数的情况下，CPU势必要通过分配时间片的方式进行线程的上下文切换，频繁的上下文切换会造成很大的性能开销。

Hikari官方给出了一个PostgreSQL数据库连接池大小的建议值公式，CPU核心数*2+1

uns Das Problem unzureichender Verbindungen kann unter zwei Aspekten gelöst werden:

1 Erhöhen Sie die Anzahl der verfügbaren Verbindungen und ändern Sie die Umgebungsvariable max_connections. Standardmäßig beträgt die maximale Anzahl von Verbindungen auf dem Server >151

mysql> show variables like 'slow_query%';
+---------------------+--------------------------------------+
| Variable_name       | Value                                |
+---------------------+--------------------------------------+
| slow_query_log      | OFF                                  |
| slow_query_log_file | /var/lib/mysql/9e74f9251f6c-slow.log |
+---------------------+--------------------------------------+
2 rows in set (0.00 sec)

2. Das Standard-Client-Timeout des Systems beträgt 28800 Sekunden (8 Stunden). Wir können diesen Wert kleiner anpassen Die meisten Parameter stellen Standardwerte bereit, die vom MySQL-Autor sorgfältig entworfen wurden und die Anforderungen der meisten Situationen vollständig erfüllen. Es wird nicht empfohlen, sie vorschnell zu ändern, ohne die Bedeutung der Parameter zu kennen.

1.2 Client-Optimierung

Was der Client tun kann, ist, die Anzahl der Verbindungen zum Server zu minimieren. Die aufgebauten Verbindungen können so weit wie möglich genutzt werden . Erstellen Sie nicht jedes Mal eine neue Verbindung, wenn Sie eine SQL-Anweisung ausführen. Die Ressourcen des Servers und des Clients werden dadurch überlastet.

Die Lösung besteht darin, den Connection Pool

zu verwenden, um Verbindungen wiederzuverwenden.

Zu den gängigen Datenbankverbindungspools gehören DBCP, C3P0, Alibaba's Druid und Hikari. Verwenden Sie die ersten beiden Es gibt nur sehr wenige, und die beiden letztgenannten befinden sich derzeit auf dem Höhepunkt.

Aber es ist zu beachten, dass je größer der Verbindungspool ist, desto besser. Beispielsweise beträgt die standardmäßige maximale Verbindungspoolgröße von Druid 8 und die standardmäßige maximale Verbindungspoolgröße von Hikari ist blind 10. Wenn Sie die Größe des Verbindungspools übermäßig erhöhen, kann die Effizienz der Systemausführung abnehmen. Warum?

Für jede Verbindung erstellt der Server einen separaten Thread, um sie zu verarbeiten. Je mehr Verbindungen vorhanden sind, desto mehr Threads erstellt der Server. Wenn die Anzahl der Threads die Anzahl der CPUs übersteigt, muss die CPU Zeitscheiben für den Kontextwechsel von Threads zuweisen. Häufiger Kontextwechsel verursacht einen hohen Leistungsaufwand. 🎜🎜Hikari-Beamter gibt einen< Code> PostgreSQLDie empfohlene Wertformel für die Größe des Datenbankverbindungspools ist Anzahl der CPU-Kerne*2+1. Unter der Annahme, dass die Anzahl der CPU-Kerne des Servers 4 beträgt, setzen Sie einfach den Verbindungspool auf 9. Diese Formel ist bis zu einem gewissen Grad auch auf andere Datenbanken anwendbar und Sie können in Interviews damit prahlen. 2. Architekturoptimierung 2.1 Cache verwenden ) , was dazu führt, dass die Abfrage die Verbindung für längere Zeit belegt. 🎜🎜Wenn die Wirksamkeit dieser Art von Daten nicht besonders stark ist (sie ändert sich nicht jeden Moment, wie z. B. tägliche Berichte), können wir diese Art von Daten in das Cache-System stellen und während der Cache-Gültigkeitsdauer der Daten Rufen Sie sie direkt aus dem Cache-System ab. Rufen Sie Daten aus der Datenbank ab, wodurch der Druck auf die Datenbank verringert und die Abfrageeffizienz verbessert werden kann. 🎜🎜🎜🎜🎜🎜2.2 Lese- und Schreibtrennung (Cluster, Master-Slave-Replikation) 🎜🎜🎜In der frühen Phase des Projekts wird die Datenbank normalerweise auf einem Server ausgeführt, und alle Lese- und Schreibanforderungen des Benutzers wirken sich direkt darauf aus Datenbankserver, schließlich ist die Menge an Parallelität, die ein einzelner Server ertragen kann, begrenzt. 🎜

Um dieses Problem zu lösen, können wir mehrere Datenbankserver gleichzeitig verwenden, einen von ihnen als Teamleiter festlegen, den sogenannten master-Knoten, und die übrigen Knoten als Teammitglieder festlegen, die als bezeichnet werden Sklave. Benutzer schreiben Daten nur auf den Master-Knoten und Leseanforderungen werden an verschiedene Slave-Knoten verteilt. Diese Lösung wird „Lese-Schreib-Trennung“ genannt. Geben Sie der kleinen Gruppe, bestehend aus dem Gruppenleiter und den Gruppenmitgliedern, einen Namen, master节点，其余节点作为组员，叫做slave。用户写数据只往master节点写，而读的请求分摊到各个slave节点上。这个方案叫做读写分离。给组长加上组员组成的小团体起个名字，叫集群。

注：很多开发者不满master-slave这种具有侵犯性的词汇（因为他们认为会联想到种族歧视、黑人奴隶等），所以发起了一项更名运动。

受此影响MySQL也会逐渐停用master、slave等术语，转而用source和replica替代，大家碰到的时候明白即可。

使用集群必然面临一个问题，就是多个节点之间怎么保持数据的一致性。毕竟写请求只往master节点上发送了，只有master节点的数据是最新数据，怎么把对master节点的写操作也同步到各个slave节点上呢？

主从复制技术来了！我在之前的文章中粗浅地介绍了一下binlog日志，我直接搬过来了。

binlog是实现MySQL主从复制功能的核心组件。master节点会将所有的写操作记录到binlog中，slave节点会有专门的I/O线程读取master节点的binlog，将写操作同步到当前所在的slaveCluster

.

Hinweis: Viele Entwickler waren mit dem beleidigenden Begriff master-slave unzufrieden (weil sie dachten, er würde mit Rassendiskriminierung, schwarzen Sklaven usw. in Verbindung gebracht), also starteten sie eine Namensänderungsbewegung.

Davon betroffen wird MySQL nach und nach auch auf die Verwendung von Begriffen wie master und slave verzichten und stattdessen source und replica< verwenden /code >Ersatz, verstehen Sie es einfach, wenn jeder darauf stößt. <strong></blockquote></strong>Bei der Verwendung eines Clusters tritt zwangsläufig das Problem auf, wie die Datenkonsistenz zwischen mehreren Knoten aufrechterhalten werden kann. Schließlich wird die Schreibanforderung nur an den <code>master-Knoten gesendet, und nur die Daten des master-Knotens sind die neuesten Daten >Master-Knoten auch durchgeführt? Mit jedem Slave-Knoten synchronisieren? Die

Master-Slave-Replikation-Technologie ist da! Ich habe das Binlog-Protokoll in meinem vorherigen Artikel kurz vorgestellt und es direkt verschoben.

binlog ist die Kernkomponente, die die MySQL-Master-Slave-Replikationsfunktion implementiert. Der Master-Knoten zeichnet alle Schreibvorgänge im Binlog auf. Der Slave-Knoten verfügt über einen dedizierten E/A-Thread zum Lesen des Binlogs des Master</code > Knoten, synchronisieren Sie den Schreibvorgang mit dem aktuellen <code>Slave-Knoten.

Diese Cluster-Architektur hat einen sehr guten Effekt auf die Reduzierung des Drucks auf den Hauptdatenbankserver. Wenn jedoch das Datenvolumen einer bestimmten Tabelle stark zunimmt, nimmt die Abfrageleistung einer einzelnen Tabelle zu Ein erheblicher Rückgang, und dieses Problem kann auch mit der Lese-/Schreibtrennung nicht gelöst werden. Natürlich ist die Leistung aller Knoten schlecht .

Zu diesem Zeitpunkt können wir die Daten eines einzelnen Knotens zur Speicherung auf mehrere Knoten verteilen. Dies ist eine

Unterdatenbank und eine Untertabelle.

2.3 Unterdatenbank und Untertabelle

Die Bedeutung von Knoten in Unterdatenbank und Untertabelle ist relativ weit gefasst. Wenn die Datenbank als Knoten verwendet wird, handelt es sich um eine Unterdatenbank Wird als Knoten verwendet, handelt es sich um eine Untertabelle.

Jeder weiß, dass Sharding in vertikales Sharding, vertikales Sharding, horizontales Sharding und horizontales Sharding unterteilt ist, aber jedes Mal, wenn ich mich nicht an diese Konzepte erinnern kann, werde ich sie im Detail erklären, um Ihnen das Verständnis zu erleichtern.

2.3.1 Vertikale Unterdatenbank

Machen Sie einige vertikale Schnitte auf der Grundlage einer einzelnen Datenbank und teilen Sie diese entsprechend der Geschäftslogik in verschiedene Datenbanken auf. Dies ist eine

vertikale Unterdatenbank.

2.3.2 Vertikale Tabellenteilung

Bei der vertikalen Tabellenteilung wird ein vertikaler Schnitt (oder mehrere Schnitte) auf der Grundlage einer einzelnen Tabelle vorgenommen und die mehreren Zeichen einer Tabelle in mehrere aufgeteilt Bei kleinen Tabellen muss dieser Vorgang entsprechend dem jeweiligen Unternehmen beurteilt werden. Normalerweise werden häufig verwendete Felder (heiße Felder) in eine Tabelle unterteilt, und Felder, die nicht häufig oder nicht sofort verwendet werden (kalte Felder), werden in eine Tabelle unterteilt Tabelle, um die Abfragegeschwindigkeit zu verbessern.

Nehmen Sie das Bild oben als Beispiel: Normalerweise sind die Produktdetails relativ lang, und beim Anzeigen der Produktliste ist es oft nicht erforderlich, die Produktdetails sofort anzuzeigen (klicken Sie im Allgemeinen auf die Schaltfläche „Details“, um sie anzuzeigen), aber Die wichtigeren Informationen zum Produkt (Preis usw.) werden angezeigt. Gemäß dieser Geschäftslogik haben wir die ursprüngliche Produkttabelle in vertikale Untertabellen unterteilt.

🎜2.3.3 Horizontale Tabellenaufteilung🎜🎜🎜Speichern Sie die Daten einer einzelnen Tabelle nach bestimmten Regeln (im Fachjargon Sharding-Regeln genannt) in mehreren Datentabellen und geben Sie den Datentabellen einen horizontalen Schnitt (oder mehrere Schnitte). ist jetzt 🎜Level-Tabelle🎜. 🎜🎜🎜🎜🎜🎜🎜

2.3.4 水平分库

水平分库就是对单个数据库水平切一刀，往往伴随着水平分表。

2.3.5 总结

水平分，主要是为了解决存储的瓶颈；垂直分，主要是为了减轻并发压力。

2.4 消息队列削峰

通常情况下，用户的请求会直接访问数据库，如果同一时刻在线用户数量非常庞大，极有可能压垮数据库（参考明星出轨或公布恋情时微博的状态）。

这种情况下可以通过使用消息队列降低数据库的压力，不管同时有多少个用户请求，先存入消息队列，然后系统有条不紊地从消息队列中消费请求。

3. 优化器——SQL分析与优化

处理完连接、优化完缓存等架构的事情，SQL查询语句来到了解析器和优化器的地盘了。在这一步如果出了任何问题，那就只能是SQL语句的问题了。

只要你的语法不出问题，解析器就不会有问题。此外，为了防止你写的SQL运行效率低，优化器会自动做一些优化，但如果实在是太烂，优化器也救不了你了，只能眼睁睁地看着你的SQL查询沦为慢查询。

3.1 慢查询

慢查询就是执行地很慢的查询（这句话说得跟废话似的。。。），只有知道MySQL中有哪些慢查询我们才能针对性地进行优化。

因为开启慢查询日志是有性能代价的，因此MySQL默认是关闭慢查询日志功能，使用以下命令查看当前慢查询状态

mysql> show variables like 'slow_query%';
+---------------------+--------------------------------------+
| Variable_name       | Value                                |
+---------------------+--------------------------------------+
| slow_query_log      | OFF                                  |
| slow_query_log_file | /var/lib/mysql/9e74f9251f6c-slow.log |
+---------------------+--------------------------------------+
2 rows in set (0.00 sec)

slow_query_log表示当前慢查询日志是否开启，slow_query_log_file表示慢查询日志的保存位置。

除了上面两个变量，我们还需要确定“慢”的指标是什么，即执行超过多长时间才算是慢查询，默认是10S，如果改成0的话就是记录所有的SQL。

mysql> show variables like '%long_query%';
+-----------------+-----------+
| Variable_name   | Value     |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+
1 row in set (0.00 sec)

3.1.1 打开慢日志

有两种打开慢日志的方式

1、修改配置文件my.cnf

此种修改方式系统重启后依然有效

# 是否开启慢查询日志
slow_query_log=ON
# 
long_query_time=2
slow_query_log_file=/var/lib/mysql/slow.log

2、动态修改参数（重启后失效）

mysql> set @@global.slow_query_log=1;
Query OK, 0 rows affected (0.06 sec)

mysql> set @@global.long_query_time=2;
Query OK, 0 rows affected (0.00 sec)

3.1.2 慢日志分析

MySQL不仅为我们保存了慢日志文件，还为我们提供了慢日志查询的工具mysqldumpslow，为了演示这个工具，我们先构造一条慢查询：

mysql> SELECT sleep(5);

然后我们查询用时最多的1条慢查询：

[root@iZ2zejfuakcnnq2pgqyzowZ ~]# mysqldumpslow -s t -t 1 -g 'select' /var/lib/mysql/9e74f9251f6c-slow.log

Reading mysql slow query log from /var/lib/mysql/9e74f9251f6c-slow.log
Count: 1  Time=10.00s (10s)  Lock=0.00s (0s)  Rows=1.0 (1), root[root]@localhost
  SELECT sleep(N)

其中，

• Count：表示这个SQL执行的次数
• Time：表示执行的时间，括号中的是累积时间
• Locks：表示锁定的时间，括号中的是累积时间
• Rows：表示返回的记录数，括号中的是累积数

更多关于mysqldumpslow的使用方式，可以查阅官方文档，或者执行mysqldumpslow --help寻求帮助。

3.2 查看运行中的线程

我们可以运行show full processlist查看MySQL中运行的所有线程，查看其状态和运行时间，找到不顺眼的，直接kill。

其中，

• Id：线程的唯一标志，可以使用Id杀死指定线程
• User：启动这个线程的用户，普通账户只能查看自己的线程
• Host：哪个ip和端口发起的连接
• db：线程操作的数据库
• Command：线程的命令
• Time：操作持续时间，单位秒
• State：线程的状态
• Info：SQL语句的前100个字符

3.3 查看服务器运行状态

使用SHOW STATUS查看MySQL服务器的运行状态，有session和global两种作用域，一般使用like+通配符进行过滤。

-- 查看select的次数
mysql> SHOW GLOBAL STATUS LIKE 'com_select';
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| Com_select    | 168241 |
+---------------+--------+
1 row in set (0.05 sec)

3.4 查看存储引擎运行信息

SHOW ENGINE用来展示存储引擎的当前运行信息，包括事务持有的表锁、行锁信息；事务的锁等待情况；线程信号量等待；文件IO请求；Buffer pool统计信息等等数据。

例如：

SHOW ENGINE INNODB STATUS;

上面这条语句可以展示innodb存储引擎的当前运行的各种信息，大家可以据此找到MySQL当前的问题，限于篇幅不在此意义说明其中信息的含义，大家只要知道MySQL提供了这样一个监控工具就行了，等到需要的时候再来用就好。

3.5 EXPLAIN执行计划

通过慢查询日志我们可以知道哪些SQL语句执行慢了，可是为什么慢？慢在哪里呢？

MySQL提供了一个执行计划的查询命令EXPLAIN，通过此命令我们可以查看SQL执行的计划，所谓执行计划就是：优化器会不会优化我们自己书写的SQL语句（比如外连接改内连接查询，子查询优化为连接查询...）、优化器针对此条SQL的执行对哪些索引进行了成本估算，并最终决定采用哪个索引（或者最终选择不用索引，而是全表扫描）、优化器对单表执行的策略是什么，等等等等。

EXPLAIN在MySQL5.6.3之后也可以针对UPDATE、DELETE和INSERT语句进行分析，但是通常情况下我们还是用在SELECT查询上。

这篇文章主要是从宏观上多个角度介绍MySQL的优化策略，因此这里不详细说明EXPLAIN的细节，之后单独成篇。

3.6 SQL与索引优化

3.6.1 SQL优化

SQL优化指的是SQL本身语法没有问题，但是有实现相同目的的更好的写法。比如：

• 使用小表驱动大表；用join改写子查询；or改成union
• 连接查询中，尽量减少驱动表的扇出（记录数），访问被驱动表的成本要尽量低，尽量在被驱动表的连接列上建立索引，降低访问成本；被驱动表的连接列最好是该表的主键或者是唯一二级索引列，这样被驱动表的成本会降到更低
• 大偏移量的limit，先过滤再排序

针对最后一条举个简单的例子，下面两条语句能实现同样的目的，但是第二条的执行效率比第一条执行效率要高得多（存储引擎使用的是InnoDB），大家感受一下：

-- 1. 大偏移量的查询
mysql> SELECT * FROM user_innodb LIMIT 9000000,10;
Empty set (8.18 sec)

-- 2.先过滤ID（因为ID使用的是索引），再limit
mysql> SELECT * FROM user_innodb WHERE id > 9000000 LIMIT 10;
Empty set (0.02 sec)

3.6.2 索引优化

为慢查询创建适当的索引是个非常常见并且非常有效的方法，但是索引是否会被高效使用又是另一门学问了。

推荐阅读：《如何用好MySQL索引？你必须了解这些事！》，感兴趣的读者可以看一下。
https://www.php.cn/mysql-tutorials-493147.html

4. 存储引擎与表结构

4.1 选择存储引擎

一般情况下，我们会选择MySQL默认的存储引擎存储引擎InnoDB，但是当对数据库性能要求精益求精的时候，存储引擎的选择也成为一个关键的影响因素。

建议根据不同的业务选择不同的存储引擎，例如：

• 查询操作、插入操作多的业务表，推荐使用MyISAM；
• 临时表使用Memory；
• 并发数量大、更新多的业务选择使用InnoDB；
• 不知道选啥直接默认。

4.2 优化字段

字段优化的最终原则是：使用可以正确存储数据的最小的数据类型。

4.2.1 整数类型

MySQL提供了6种整数类型，分别是

• tinyint
• smallint
• mediumint
• int
• integer
• bigint

不同的存储类型的最大存储范围不同，占用的存储的空间自然也不同。

例如，是否被删除的标识，建议选用tinyint，而不是bigint。

4.2.2 字符类型

你是不是直接把所有字符串的字段都设置为varchar格式了？甚至怕不够，还会直接设置成varchar(1024)的长度？

如果不确定字段的长度，肯定是要选择varchar，但是varchar需要额外的空间来记录该字段目前占用的长度；因此如果字段的长度是固定的，尽量选用char，这会给你节约不少的内存空间。

4.2.3 Nicht-Null-Felder

Nicht-Null-Felder sollten so oft wie möglich auf NOT NULL gesetzt werden und einen Standardwert bereitstellen oder spezielle Werte anstelle von verwenden NULL. NOT NULL，并提供默认值，或者使用特殊值代替NULL。

因为NULL类型的存储和优化都会存在性能不佳的问题，具体原因在这里就不展开了。

4.2.4 不要用外键、触发器和视图功能

这也是「阿里巴巴开发手册」中提到的原则。原因有三个：

• 降低了可读性，检查代码的同时还得查看数据库的代码；

• 把计算的工作交给程序，数据库只做好存储的工作，并把这件事情做好；

• 数据的完整性校验的工作应该由开发者完成，而不是依赖于外键，一旦用了外键，你会发现测试的时候随便删点垃圾数据都变得异常艰难。

4.2.5 图片、音频、视频存储

不要直接存储大文件，而是要存储大文件的访问地址。

4.2.6 大字段拆分和数据冗余

大字段拆分其实就是前面说过的垂直分表，把不常用的字段或者数据量较大的字段拆分出去，避免列数过多和数据量过大，尤其是习惯编写SELECT *

Da die Speicherung und Optimierung des Typs NULL zu Leistungsproblemen führt, werden die spezifischen Gründe hier nicht erläutert.

4.2.4 Verwenden Sie keine Fremdschlüssel, Trigger und Ansichtsfunktionen

Dies ist auch ein Prinzip, das im „Alibaba Development Manual“ erwähnt wird. Dafür gibt es drei Gründe:

verringert die Lesbarkeit, und Sie müssen gleichzeitig den Code der Datenbank überprüfen;

• Überlassen Sie die Berechnungsarbeit dem Programm, und die Datenbank übernimmt nur die Speicherarbeit, und das tut sie auch Machen Sie es gut.

Die Arbeit der Datenintegritätsüberprüfung sollte von Entwicklern durchgeführt werden, anstatt sich auf Fremdschlüssel zu verlassen. Sobald Fremdschlüssel verwendet werden, wird es äußerst schwierig, Junk-Daten während des Tests zu löschen. .

• 4.2.5 Bild-, Audio-, Videospeicherung

• Speichern Sie große Dateien nicht direkt, sondern speichern Sie die Zugriffsadresse großer Dateien.

  4.2.6 Aufteilung großer Felder und Datenredundanz

---

Aufteilung großer Felder

Tatsächlich ist es die zuvor erwähnte vertikale Tabellenpartitionierung, die die selten verwendeten Felder trennt bzw. trennt Teilen Sie die Felder mit großem Datenvolumen auf, um zu viele Spalten und ein zu großes Datenvolumen zu vermeiden. Insbesondere wenn Sie es gewohnt sind, SELECT * zu schreiben, werden Probleme, die durch eine große Anzahl von Spalten und ein großes Datenvolumen verursacht werden, beseitigt. Ernsthaft verstärkt!

Feldredundanz

entspricht im Prinzip nicht dem Datenbankdesign-Paradigma, ist aber für einen schnellen Abruf sehr förderlich. Wenn beispielsweise die Kunden-ID in der Vertragstabelle gespeichert wird, kann der Kundenname redundant gespeichert werden, sodass bei der Abfrage kein Benutzername basierend auf der Kunden-ID ermittelt werden muss. Daher ist es auch eine bessere Optimierungstechnik, ein gewisses Maß an Redundanz für die Geschäftslogik zu schaffen. 🎜🎜🎜5. Geschäftsoptimierung ist streng genommen kein Mittel zur MySQL-Optimierung, aber Geschäftsoptimierung kann den Datenbankzugriffsdruck sehr effektiv reduzieren. Hier sind ein paar einfache Beispiele Um Ihnen einige Ideen zu geben: 🎜🎜🎜🎜In der Vergangenheit begann das Kaufmodell in der Nacht von Double 11. In den letzten Jahren wurde die Vorverkaufsfrist für Double 11 immer länger und begann nach mehr als einem halben Monat Es entstehen verschiedene Einzahlungsmodelle mit roten Umschlägen. Diese Methode wird als „Vorverkaufsumleitung“ bezeichnet. Dadurch können Serviceanfragen der Kunden umgeleitet werden, und Sie müssen nicht bis zum frühen Morgen von Double Eleven warten, um gemeinsam Bestellungen aufzugeben. 🎜🎜🎜🎜Am frühen Morgen von Double Eleven möchten Sie möglicherweise Bestellungen außerhalb dieses Tages überprüfen , aber die Abfrage schlägt fehl; selbst in Alipay wurden die Rationen verzögert. Dies ist eine „Downgrade-Strategie“, die Rechenressourcen für unwichtige Dienste sammelt, um das aktuelle Kerngeschäft sicherzustellen Elf. Huabei-Zahlung anstelle von Bankkartenzahlung. Obwohl ein Teil der Überlegungen darin besteht, die Stabilität der Software zu verbessern, bietet die Verwendung des von Yu'ebao tatsächlich verwendeten internen Servers von Alibaba eine schnelle Zugriffsgeschwindigkeit, während die Verwendung von Bankkarten erforderlich ist Der Aufruf der Bankschnittstelle ist im Vergleich dazu deutlich langsamer. 🎜🎜🎜🎜🎜Dies ist das Ende der Zusammenfassung der MySQL-Optimierung. Es werden viele Details nicht erwähnt, weshalb ich das Gefühl habe, dass dieser Artikel nicht perfekt ist. Es gibt jedoch zu viele Wissenspunkte, um sie im Detail zu behandeln. Es ist unmöglich, sie alle auf einmal aufzuschreiben. 🎜🎜【Verwandte Empfehlung: 🎜MySQL-Video-Tutorial🎜】🎜