Methoden zur Leistungsoptimierung und zum Testen von MySQL
- 一个新手Original
- 2017-10-24 10:24:391713Durchsuche
Nachdem unser MySQL-Dienst eine Zeit lang ausgeführt wurde, wird er aus unbekannten Gründen langsamer. Wie können wir den Grund herausfinden?
1. Schlüsselindikatoren
Bei der Bewertung der Datenbankleistung sind mehrere Indikatoren sehr wichtig, unabhängig davon, wie wichtig sie sind . , aber sie können die Fähigkeiten der Datenbank in bestimmten Aspekten klarer darstellen.
1.IOPS
IOPS: Eingabe-/Ausgabevorgang pro Sekunde, die Anzahl der pro Sekunde verarbeiteten E/A-Anfragen.
Wir wissen, dass E/A die Lese- und Schreibfähigkeit der Festplatte ist. Beispielsweise ist das Lesen von 300 MB pro Sekunde und das Schreiben von 200 MB der Datendurchsatz (ein weiterer wichtiger Indikator für die E/A-Fähigkeit), aber IOPS bedeutet nicht Lese- und Schreibdatendurchsatz, IOPS bezieht sich auf 每秒能够处理的 I/O 请求次数.
Wenn Sie möchten, dass das E/A-System schnell genug reagiert, ist es umso besser, da IOPS mit der Hardware zusammenhängt. Um IOPS zu verbessern, besteht die aktuelle Lösung im Wesentlichen darin, Hardware zu verwenden Die Lösung besteht darin, mehrere zu verwenden. Nachdem die Blockplatte das RAID-Striping bestanden hat, werden die E/A-Lese- und Schreibfunktionen verbessert. Wir können auch Solid-State-Laufwerke (SSDs) verwenden, um die IOPS zu erhöhen, aber die Kosten für SSDs können relativ hoch sein.
2.QPS
QPS: Query Per Second, die Anzahl der Anfragen (Abfragen) pro Sekunde.
Dieser Parameter ist sehr wichtig und kann intuitiv die Leistung des Systems widerspiegeln. Es ist wie IOPS, das misst, wie viele Anfragen eine Festplatte pro Sekunde empfangen kann.
Wir können den Befehl status im MySQL-Befehlszeilenmodus ausführen und die letzte Zeile der zurückgegebenen Ausgabeinformationen enthält den QPS-Indikator.
3.TPS
TPS: Transaktion pro Sekunde, Anzahl der Transaktionen pro Sekunde.
TPS-Parameter werden von MySQL nicht nativ bereitgestellt. Wenn wir sie selbst berechnen müssen, können wir die Berechnungsformel verwenden:
TPS = (Com_commit + Com_rollback) / Seconds
Diese Formel hat zwei Statusvariablen, die die Anzahl der Übermittlungen und die Anzahl der Übermittlungen darstellen Anzahl der Rollbacks ist das von uns definierte Zeitintervall.
2. Schlüsselindikatoren des TPCC-Tests
TPCC-MySQL ist ein von Percona entwickeltes MySQL-Benchmark-Testprogramm, das auf der TPCC-Spezifikation basiert .
1. Installation und Verwendung des TPCC-Tools
Für eine spezifische Installation können Sie diese beiden Blogbeiträge über die Installation und Verwendung des MySQL-Stresstesttools tpcc-mysql, den MySQL-Leistungstest-tpcc und TPCC lesen ist besser in der Lage, Online-Geschäfte zu simulieren.
3. Optimierung der Datenbankparameterkonfiguration
Wenn die Datenbankparameter angemessen konfiguriert sind, kann die Betriebseffizienz erheblich verbessert werden, dh die Nutzung der Systemressourcen kann maximiert werden.
1. Verbindungsbezogene Parameter
1.1 max_connections
max_connections: Geben Sie den MySQL-Server an 最大并发连接数, der Wert reicht von 1 bis 100.000, der Standardwert ist 151.
Dieser Parameter ist sehr wichtig, da er die maximale Anzahl von Sitzungen bestimmt, die gleichzeitig mit dem MySQL-Dienst verbunden werden können. Bei der Einstellung dieses Parameters ist es je nach Konfiguration und Leistung des Datenbankservers im Allgemeinen kein großes Problem, den Parameterwert zwischen 500 und 2000 festzulegen.
1.2 max_connect_errors
max_connect_errors: 指定允许连接不成功的最大尝试次数, der Wert reicht von 1~2^64, der Standardwert ist 100 in Version 5.6.6.
Ignorieren Sie diesen Parameter nicht, wenn die Anzahl der Verbindungsversuche den durch diesen Parameter angegebenen Wert überschreitet. Ja, er lehnt die Verbindung ab weiterhin Dienste bereitstellt, kann dies nicht erfolgen. Eine neue Verbindung wird erstellt. Sie können FLUSH HOSTS verwenden, um den Status zu löschen oder den Datenbankdienst neu zu starten, aber die Kosten sind zu hoch und Sie tun dies im Allgemeinen nicht, also 这个参数的默认值太小，这里建议将之设置为 10 万以上的量级.
1.3 Interactive_Timeout und Wait_Timeout
Beide Parameter beziehen sich auf das automatische Timeout der Verbindungssitzung. Ersteres wird verwendet, um die Wartezeit vor dem Schließen der interaktiven Verbindung anzugeben, und letzteres wird verwendet Geben Sie das Schließen nicht interaktiver Verbindungen an. Die Einheit ist Sekunden, der Standardwert ist 28800, also 8 Stunden.
1.4 Skip-Name-Resolve: Es kann einfach als Deaktivierung der DNS-Auflösung verstanden werden. Beachten Sie, dass dies das Verhalten des Servers ist und der Client nicht überprüft wird Verbindung herstellen. Wenn dieser Parameter angegeben wird, muss die HOST-Spalte beim Erstellen eines Benutzers und beim Erteilen von Berechtigungen eine IP und kein Hostname sein. Es wird empfohlen, diesen Parameter zu aktivieren, um die Netzwerkverbindung zu beschleunigen. Dies entspricht dem Überspringen der Hostnamenauflösung.
1.5 back_log
back_log: Geben Sie MySQL
an, in der Version 连接请求队列中存放的最大连接请求数量 ist der Standardwert 50 und der Maximalwert überschreitet 65535 nicht. In der 5.6.6-Version von 前 ist der Standardwert -1, was bedeutet, dass er von MySQL automatisch angepasst wird. Es gibt tatsächlich Regeln, die 50+ (max_connections/5) betragen. 5.6.6后Dieser Parameter wird hauptsächlich verwendet, um eine große Anzahl von Verbindungsanfragen in kurzer Zeit zu bearbeiten. Der MySQL-Hauptthread kann nicht rechtzeitig Verbindungsthreads für jede Verbindungsanfrage zuweisen (oder erstellen). ? Es kann nicht direkt abgelehnt werden,
2.文件相关参数
2.1 sync_binlog
sync_binlog：指定同步二进制日志文件的平率，默认为0.
如果要性能，则指定该参数为0，为了安全起见则指定该参数值为 1.
2.2 expire_logs_day
expire_logs_day：指定设置二进制日志文件的生命周期，超出则将自动被删除，参数值以天为单位，值得范围从0~99，默认值是0，建议将该参数设置为 7~14 之间，保存一到两周就足够了。
2.2 max_binlog_size
max_binlog_size： 指定二进制日志的大小，值得范围从 4KB~1GB，默认为 1GB。
3.缓存控制参数
3.1 thread_cache_size
thread_cache_size:指定MySQL为快速重用而缓存的线程数量。值得范围从 0~16384，默认值为0.
一般当客户端中断连接后，为了后续再有连接创建时，能够快速创建成功，MySQL 会将客户端中断的连接放入缓存区，而不是马上中断释放资源。这样当有新的客户端请求连接时，就可以快速创建成功。因此，本参数最好保持一定的数量，建议设置在 300~500 之间均可.另外，线程缓存的命中率也是一项比较重要的监控指标，计算规则为（1-Threads_created/Connections）* 100%,我们可以通过该指标来优化和调整thread_cache_size参数。
3.2 query_cache_type
sql_cache意思是说，将查询结果放入查询缓存中。
sql_no_cache意思是查询的时候不缓存查询结果。
sql_buffer_result意思是说，在查询语句中，将查询结果缓存到临时表中。
这三者正好配套使用。sql_buffer_result将尽快释放表锁，这样其他sql就能够尽快执行。
使用 FLUSH QUERY CACHE 命令，你可以整理查询缓存，以更好的利用它的内存。这个命令不会从缓存中移除任何查询。FLUSH TABLES 会转储清除查询缓存。
RESET QUERY CACHE 使命从查询缓存中移除所有的查询结果。
那么mysql到底是怎么决定到底要不要把查询结果放到查询缓存中呢？
是根据query_cache_type这个变量来决定的。
这个变量有三个取值：0,1,2，分别代表了off、on、demand。
mysql默认为开启 on
意思是说，如果是0，那么query cache 是关闭的。
如果是1，那么查询总是先到查询缓存中查找，即使使用了sql_no_cache仍然查询缓存，因为sql_no_cache只是不缓存查询结果，而不是不使用查询结果。
select count(*) from innodb; 1 row in set (1.91 sec) select sql_no_cache count(*) from innodb; 1 row in set (0.25 sec)
如果是2，DEMAND。
在my.ini中增加一行
query_cache_type=2
重启mysql服务
select count(*) from innodb; 1 row in set (1.56 sec) select count(*) from innodb; 1 row in set (0.28 sec)
没有使用sql_cache,好像仍然使用了查询缓存
select sql_cache count(*) from innodb; 1 row in set (0.28 sec)
使用sql_cache查询时间也一样，因为sql_cache只是将查询结果放入缓存，没有使用sql_cache查询也会先到查询缓存中查找数据
结论：只要query_cache_type没有关闭，sql查询总是会使用查询缓存，如果缓存没有命中则开始查询的执行计划到表中查询数据。
query cache优缺点
优点很明显，对于一些频繁select query，mysql直接从cache中返回相应的结果集，而不用再从表table中取出，减少了IO开销。
即使query cache的收益很明显，但是也不能忽略它所带来的一些缺点：
query语句的hash计算和hash查找带来的资源消耗。mysql会对每条接收到的select类型的query进行hash计算然后查找该query的cache是否存在，虽然hash计算和查找的效率已经足够高了，一条query所带来的消耗可以忽略，但一旦涉及到高并发，有成千上万条query时，hash计算和查找所带来的开销就的重视了；
query cache的失效问题。如果表变更比较频繁，则会造成query cache的失效率非常高。表变更不仅仅指表中的数据发生变化，还包括结构或者索引的任何变化；
对于不同sql但同一结果集的query都会被缓存，这样便会造成内存资源的过渡消耗。sql的字符大小写、空格或者注释的不同，缓存都是认为是不同的sql（因为他们的hash值会不同）；
相关参数设置不合理会造成大量内存碎片，相关的参数设置会稍后介绍。
合理利用query cache
query cache有利有弊，合理的使用query cache可以使其发挥优势，并且有效的避开其劣势。
并不是所有表都适合使用query cache。造成query cache失效的原因主要是相应的table发生了变更，那么就应该避免在变化频繁的table上使用query cache。mysql中针对query cache有两个专用的sql hint：SQL_NO_CACHE和SQL_CACHE，分别表示强制不使用和强制使用query cache，通过强制不使用query cache，可以让mysql在频繁变化的表上不使用query cache，这样减少了内存开销，也减少了hash计算和查找的开销；
更多有关query cache详情文章，请看这里的原文：mysql query cache优化
3.3 query_cache_size
query_cache_size：指定用于缓存查询结果集的内存区大小，该参数值应为 1024 的整数倍。
这个参数不能太大，也不能太小，查询缓存至少会需要 40KB 的空间分配给其自身结构，太小时缓存结果集就没有意义，热点数据保存不了多少，而且总是很快就被刷新出去；但也不能太大，否则可能过多占用内存资源，影响整机性能，再说太大也没有意义，因为即便数据不被刷新，但只要源数据发生变更，缓存中的数据也就自动失效了，这种情况下分配多大都没有意义。个人建议设置不要超过 256MB。
3.4 query_cache_limit
query_cache_limit：用来控制查询缓存，能够缓存的单条 SQL 语句生成的最大结果集，默认是 1MB，超出的就不要进入查询缓存。这个大小对于很多场景都够了，缩小可以考虑，加大就不用了。
3.5 sort_buffer_size
sort_buffer_size：指定单个会话能够使用的排序区的大小，默认值为 256KB，建议设置为 1~4MB 之间。
3.6 read_buffer_size
read_buffer_size:指定随机读取时的数据缓存区大小，默认是 256KB，最大能够支持4GB，适当加大本参数，对于提升全表扫描的效率会有帮助。
4.InnoDB专用参数
4.1 innodb_buffer_pool_size
innodb_buffer_pool_size：指定InnoDB引擎专用的缓存区大小，用来缓存表对象的数据及索引信息，默认值为 128MB，最大能够支持（2^64 -1）B.
如果你有很多事务的更新，插入或删除很操作，通过修改innodb_buffer_pool 大小这个参数会大量的节省了磁盘I / O。
innodb_buffer_pool_size 是个全局参数，其所分配的缓存区将供所有被访问到的InnoDb表对象使用，若MySQL数据库中的表对象以 InnoDb 为主，那么本参数的值就越大越好，官方文档中建议，可以将该参数设置为服务器物理内存的70%~80%。
4.2 innodb_buffer_instances
innodb_buffer_instances：指定 InnoDB 缓存池分为多少个区域来使用，值得范围从 1~64，默认值为-1，表示由 InnoDB 自行调整。
只有当innodb_buffer_pool_size参数值大于1GB时，本参数才有效，那么本参数怎么设置呢？个人感觉可以参照 InnoDB 缓存池的大小，以 GB 为单位，每GB指定一个instances。例如当innodb_buffer_pool_size设置为16GB时，则指定 innodb_buffer_instances 设置为 16 即可。
5.参数优化案例
测试服务器有 16GB的物理内存，假定其峰值最大的连接数为 500 个，表对象使用InnoDB 存储引擎，我们的内存参数如何配置呢？
具体配置如下：
（1）、首先，为操作系统预留 20% 的内存，约为 3GB。
（2）、与线程相关的几个关键参数设置如下：
sort_buffer_size=2m read_buffer_size=2m read_rnd_buffer_size=2m join_buffer_size=2m
预计连接数达到峰值时，线程预计最大将有可能占用 500 *（2+2+2+2）= 4GB内存（理论最大值）。
（3）、剩下的空间 16-3-4=9GB，就可以全部都分配给InnoDB 的缓存池，设定相关的参数如下：
innodb_buffer_pool_size=9g innodb_thread_concurrency=8 innodb_flush_method=O_DIRECT innodb_log_buffer_size=16m innodb_flush_log_at_trx_commit=2
四、MySQL系统状态
想要了解MySQL服务当前在做什么，有个非常重要并且极为常用的命令：
SHOW [FULL] PROCESSLIST
SHOW PROCESSLIST 命令将每一个连接的线程，作为一条独立的记录输出。
还有相似的语句，
SHOW PROFILES 和 SHOW PROFILE可以获取会话执行语句过程中，资源的使用情况。
Das obige ist der detaillierte Inhalt vonMethoden zur Leistungsoptimierung und zum Testen von MySQL. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!