【发布时间】:2018-06-17 16:54:14
【问题描述】:
下午好。该站点位于 VPS(10 GB RAM、2 个 CPU 内核、65 GB SSD)上。 我想提高网站的速度。 但是我不明白mysql的所有参数。 我写出了当前的 mysql 设置,以及 mysqltuner 的建议。 在这个项目中,我们不会在代码中分配资源进行分析和修改。 我想通过设置获得速度增益。 如果可能的话。 谢谢。
当前 Mysql 设置
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock
[mysqld_safe]
log-error=/var/log/mysql.log
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
nice = 0
[mysqld]
local-infile=0
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
explicit_defaults_for_timestamp
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address = 127.0.0.1
log-error = /var/log/mysql/error.log
# Recommended in standard MySQL setup
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# * IMPORTANT: Additional settings that can override those from this file!
# The files must end with '.cnf', otherwise they'll be ignored.
#
!includedir /etc/mysql/conf.d/
[mysqld]
key_buffer_size = 8388608
innodb_buffer_pool_size = 368M
query_cache_size = 32M
max_heap_table_size = 147M
tmp_table_size = 147M
join_buffer_size = 1887K
innodb_flush_log_at_trx_commit = 2
explicit_defaults_for_timestamp = 0
sql_mode=
query_cache_type = 1
bind-address = 127.0.0.1
Mysqltuner 参考
>> MySQLTuner 1.3.0 - Major Hayden <major@mhtx.net>
>> Bug reports, feature requests, and downloads at http://mysqltuner.com/
>> Run with '--help' for additional options and output filtering
[OK] Logged in using credentials from debian maintenance account.
[OK] Currently running supported MySQL version 5.6.40
[OK] Operating on 64-bit architecture
-------- Storage Engine Statistics -------------------------------------------
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MRG_MYISAM
[--] Data in MyISAM tables: 37M (Tables: 5)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 52)
[--] Data in InnoDB tables: 7G (Tables: 818)
[!!] Total fragmented tables: 79
-------- Security Recommendations -------------------------------------------
[OK] All database users have passwords assigned
-------- Performance Metrics -------------------------------------------------
[--] Up for: 37d 5h 54m 55s (190M q [59.283 qps], 3M conn, TX: 861B, RX: 188B)
[--] Reads / Writes: 52% / 48%
[--] Total buffers: 571.0M global + 2.7M per thread (151 max threads)
[OK] Maximum possible memory usage: 981.4M (9% of installed RAM)
[OK] Slow queries: 0% (846/190M)
[OK] Highest usage of available connections: 43% (66/151)
[OK] Key buffer size / total MyISAM indexes: 8.0M/4.5M
[OK] Key buffer hit rate: 100.0% (5B cached / 4K reads)
[OK] Query cache efficiency: 81.3% (120M cached / 148M selects)
[!!] Query cache prunes per day: 305162
[OK] Sorts requiring temporary tables: 0% (43K temp sorts / 6M sorts)
[!!] Joins performed without indexes: 65951
[!!] Temporary tables created on disk: 42% (4M on disk / 9M total)
[OK] Thread cache hit rate: 99% (3K created / 3M connections)
[OK] Table cache hit rate: 53% (1K open / 3K opened)
[OK] Open file limit used: 0% (61/16K)
[OK] Table locks acquired immediately: 99% (116M immediate / 116M locks)
[!!] InnoDB buffer pool / data size: 368.0M/7.6G
[OK] InnoDB log waits: 0
-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
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 without LIMIT clauses
Variables to adjust:
query_cache_size (> 32M)
join_buffer_size (> 1.8M, or always use indexes with joins)
tmp_table_size (> 147M)
max_heap_table_size (> 147M)
innodb_buffer_pool_size (>= 7G)
【问题讨论】:
-
这不是在 stackoverflow 上要问的问题,因为它与编程问题无关,也没有描述特定问题。 stackoverflow.com/help/how-to-ask
-
实际上,您需要 a) 对 MySQL 作为数据库平台有足够的了解,以确保您从所支付的资源中获得可观的性能,b) 非常了解 MySQL(和一般 SQL)的开发人员足以明智地使用这些资源并适当地调整它们的使用。平台本身永远无法摆脱 /all/ 坏 SQL 的影响,无论您投入多少硬件和 SQL 配置。让您的开发人员在交付成果中正确调整和分析他们的 SQL(任何专业开发人员都应该这样做)。
-
@capricorn 请善待 Borada32 并告诉他/她在哪里发布这种性质的问题。这与 2018 年 6 月 4 日的 SO question 50680294 惊人地相似。我们知道他/她是 MySQL 新手,请尽可能多地提供指导。
标签: mysql database-tuning mysqltuner