MySQL Tunner：磁盘上创建的临时表比率高-网站响应慢

我正在使用一个带有以下规范的专用服务器，用于joomla CMS的单个网站，该网站是基于新闻/博客的网站： 英特尔（R）至强（R）CPU E5-2670 v2@2.50GHz 10芯，20螺纹 内存：60GB SSD:250（我认为是操作系统和数据库） 硬盘驱动器：2TB

PHP7.3

MySQL 5.7

网站加载时间很慢，我优化了页面，但服务器响应时间很慢，所以我只安装了Mysql Tunner来检查数据库状态。我只是查看一下报告，但我不知道是好是坏。 需要你有价值的详细指南

 >>  MySQLTuner 1.7.15 - Major Hayden <major@mhtx.net>
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.7.27
[OK] Operating on 64-bit architecture

-------- Log file Recommendations ------------------------------------------------------------------
[--] Log file: /var/log/mysqld.log(2M)
[OK] Log file /var/log/mysqld.log exists
[OK] Log file /var/log/mysqld.log is readable.
[OK] Log file /var/log/mysqld.log is not empty
[OK] Log file /var/log/mysqld.log is smaller than 32 Mb
[!!] /var/log/mysqld.log contains 2231 warning(s).
[!!] /var/log/mysqld.log contains 5891 error(s).

-------- Storage Engine Statistics -----------------------------------------------------------------
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MEMORY +MRG_MYISAM +MyISAM +PERFORMANCE_SCHEMA 
[--] Data in MyISAM tables: 431.8K (Tables: 60)
[--] Data in InnoDB tables: 1.4G (Tables: 363)
[--] Data in MEMORY tables: 0B (Tables: 8)
[OK] Total fragmented tables: 0

-------- Analysis Performance Metrics --------------------------------------------------------------
[--] innodb_stats_on_metadata: OFF
[OK] No stat updates during querying INFORMATION_SCHEMA.

-------- CVE Security Recommendations --------------------------------------------------------------
[OK] NO SECURITY CVE FOUND FOR YOUR VERSION

-------- Performance Metrics     -----------------------------------------------------------------------
[--] Up for: 12d 2h 14m 35s (153M q [146.876 qps], 4M conn, TX: 1441G, RX: 39G)
[--] Reads / Writes: 92% / 8%
[--] Binary logging is disabled
[--] Physical Memory     : 55.5G
[--] Max MySQL memory    : 8.2G
[--] Other process memory: 0B
[--] Total buffers: 8.1G global + 1.1M per thread (80 max threads)
[--] P_S Max memory usage: 0B
[--] Galera GCache Max memory usage: 0B
[OK] Maximum reached memory usage: 8.1G (14.59% of installed RAM)
[OK] Maximum possible memory usage: 8.2G (14.73% of installed RAM)
[OK] Overall possible memory usage with other process is compatible with memory available
[OK] Slow queries: 0% (0/153M)
[OK] Highest usage of available connections: 12% (10/80)
[OK] Aborted connections: 0.08%  (3729/4397307)
[!!] Query cache may be disabled by default due to mutex contention.
[!!] Query cache efficiency: 0.0% (0 cached / 119M selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (23K temp sorts / 25M sorts)
[!!] Joins performed without indexes: 52200
[!!] Temporary tables created on disk: 92% (14M on disk / 15M total)
[OK] Thread cache hit rate: 99% (10 created / 4M connections)
[!!] Table cache hit rate: 1% (1K open / 101K opened)
[OK] Open file limit used: 0% (11/10K)
[OK] Table locks acquired immediately: 100% (107K immediate / 107K locks)

-------- Performance schema ------------------------------------------------------------------------
[--] Performance schema is disabled.
[--] Memory used by P_S: 0B
[--] Sys schema is installed.

-------- ThreadPool Metrics ------------------------------------------------------------------------
[--] ThreadPool stat is disabled.

-------- MyISAM Metrics ----------------------------------------------------------------------------
[!!] Key buffer used: 18.3% (1M used / 8M cache)
[OK] Key buffer size / total MyISAM indexes: 8.0M/221.0K
[OK] Read Key buffer hit rate: 99.2% (61K cached / 507 reads)
[!!] Write Key buffer hit rate: 65.7% (105 cached / 69 writes)

-------- InnoDB Metrics ----------------------------------------------------------------------------
[--] InnoDB is enabled.
[--] InnoDB Thread Concurrency: 0
[OK] InnoDB File per table is activated
[OK] InnoDB buffer pool / data size: 8.0G/1.4G
[!!] Ratio InnoDB log file size / InnoDB Buffer pool size (3.125 %): 128.0M * 2/8.0G should be equal to 25%
[OK] InnoDB buffer pool instances: 8
[--] Number of InnoDB Buffer Pool Chunk : 64 for 8 Buffer Pool Instance(s)
[OK] Innodb_buffer_pool_size aligned with Innodb_buffer_pool_chunk_size & Innodb_buffer_pool_instances
[OK] InnoDB Read buffer efficiency: 100.00% (426722546739 hits/ 426722621278 total)
[!!] InnoDB Write Log efficiency: 80.95% (42826081 hits/ 52905097 total)
[OK] InnoDB log waits: 0.00% (0 waits / 10079016 writes) 

[--] AriaDB is disabled.
[--] TokuDB is disabled.
[--] XtraDB is disabled.
[--] Galera is disabled.

-------- Replication Metrics -----------------------------------------------------------------------
[--] Galera Synchronous replication: NO
[--] No replication slave(s) for this server.
[--] Binlog format: ROW
[--] XA support enabled: ON
[--] Semi synchronous replication Master: Not Activated
[--] Semi synchronous replication Slave: Not Activated
[--] This is a standalone server

-------- Recommendations ---------------------------------------------------------------------------
<b>General recommendations:</b>
Control warning line(s) into /var/log/mysqld.log file
Control error line(s) into /var/log/mysqld.log file
Adjust your join queries to always utilize indexes
When making adjustments, make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries which have no LIMIT clause
Increase table_open_cache gradually to avoid file descriptor limits
Read this before increasing table_open_cache over 64: 
Read this before increasing for MariaDB https://mariadb.com/kb/en/library/optimizing-table_open_cache/
This is MyISAM only table_cache scalability problem, InnoDB not affected.
See more details here: https://bugs.mysql.com/bug.php?id=49177
This bug already fixed in MySQL 5.7.9 and newer MySQL versions.
Beware that open_files_limit (10000) variable 
should be greater than table_open_cache (2000)
Performance schema should be activated for better diagnostics
Before changing innodb_log_file_size and/or innodb_log_files_in_group     read this:  
<b>Variables to adjust:</b>
query_cache_size (=0)
query_cache_type (=0)
query_cache_limit (> 1M, or use smaller result sets)
join_buffer_size (> 256.0K, or always use indexes with JOINs)
tmp_table_size (> 64M)
max_heap_table_size (> 64M)
table_open_cache (> 2000)
performance_schema = ON enable PFS
innodb_log_file_size should be (=1G) if possible, so InnoDB total log files size equals to 25% of buffer pool size.

---

关于你的my.CNF[myqLDL]部分

的建议

tmp_table_size=256M  # from 64M to expand capacity
max_heap_table_size=256M  # to expand and reduce created_tmp_disk_tables
innodb_flushing_avg_loops=5  # from 30 to reduce innodb_buffer_pool_pages_dirty
innodb_io_capacity=1900  # from 200 to enable additional SSD IOPS
innodb_buffer_pool_size=16G  # from 8G to expand capacity
innodb_change_buffer_max_size=50  # from 25 percent to accommodate adding ROWS frequently

---

免责声明：我是我的简介中提到的网站的内容作者，网络简介包括可下载的免费实用脚本、附加的建议选项、联系信息。

为您的my.CNF[mysLDL]部分

考虑的建议。

tmp_table_size=256M  # from 64M to expand capacity
max_heap_table_size=256M  # to expand and reduce created_tmp_disk_tables
innodb_flushing_avg_loops=5  # from 30 to reduce innodb_buffer_pool_pages_dirty
innodb_io_capacity=1900  # from 200 to enable additional SSD IOPS
innodb_buffer_pool_size=16G  # from 8G to expand capacity
innodb_change_buffer_max_size=50  # from 25 percent to accommodate adding ROWS frequently

---

免责声明：我是我的个人资料中提到的网站的内容作者，网络个人资料包括可下载的免费实用程序脚本、附加建议选项、联系信息。

查询时间：4.012262锁定时间：0.000219行发送：28行检查：121584选择I.*，c.name作为categoryname，c.id作为categoryid，c.alias作为categoryalias，c.params作为categoryparams从y_k2_项目中作为i右键连接y_k2_类别作为c ON c.id=i.catid，其中i.published=1和i.access IN（1,1）和i.trash=0，c.published=1和c.access IN（1,1）和c.trash=0和（i.publish_up='0000-00-00:00'或i.publish_up='2019-08-21 09:07:45'）和c.id IN（100,1,3，依此类推）订单按i.DESC限制， 28;上述查询在慢速查询日志文件中重复，查询时间从2秒到8秒不等。。。如何优化或解决此问题issue@WilsonHauck请检查请立即检查…pastebin.com/vsw3UyE1Query\u时间：4.012262锁定时间：0.000219行\u发送：28行\u检查：121584选择i.*，c.name作为categoryname，c.id作为categoryid，c.alias作为categoryalias，c.params作为categoryparams从y_k2_项目中作为i右键连接y_k2_类别作为c ON c.id=i.catid，其中i.published=1和i.access IN（1,1）和i.trash=0，c.published=1和c.access IN（1,1）和c.trash=0和（i.publish_up='0000-00-00:00'或i.publish_up='2019-08-21 09:07:45'）和c.id IN（100,1,3，依此类推）订单按i.DESC限制， 28;上述查询在慢速查询日志文件中重复，查询时间从2秒到8秒不等。。。如何优化或解决此问题issue@WilsonHauck请检查请立即检查…pastebin.com/vsw3UyE1