我在优化 VPS(Linux / Cpanel)mysql 设置时遇到了一些问题。我对 Mysql 不太了解,我将这台 VPS 用于大约 50 个不同的网站。这些网站每天的访客都不足 100 人,因此流量不是我的问题。我的 VPS 目前运行良好,但我担心 mysqltuner.pl 中的 [!!] 警告,我需要担心吗?
=> 我的 VPS 信息:
Processor Information
**Total processors: 6**
Processor #1
Vendor
GenuineIntel
Name
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
Speed
2394.454 MHz
Cache
15360 KB
Processor #2
Vendor
GenuineIntel
Name
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
Speed
2394.454 MHz
Cache
15360 KB
Processor #3
Vendor
GenuineIntel
Name
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
Speed
2394.454 MHz
Cache
15360 KB
Processor #4
Vendor
GenuineIntel
Name
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
Speed
2394.454 MHz
Cache
15360 KB
Processor #5
Vendor
GenuineIntel
Name
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
Speed
2394.454 MHz
Cache
15360 KB
Processor #6
Vendor
GenuineIntel
Name
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
Speed
2394.454 MHz
Cache
15360 KB
Memory Information
Memory: 30789880k/**32505856k** available (5336k kernel code, 1050056k absent, 665920k reserved, 7016k data, 1288k init)
System Information
Linux xl.xlxlxl.com 2.6.32-504.12.2.el6.x86_64 #1 SMP Wed Mar 11 22:03:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Current Memory Usage
total used free shared buffers cached
Mem: 30812400 30064332 748068 244 3883652 17129112
-/+ buffers/cache: 9051568 21760832
Swap: 0 0 0
Total: 30812400 30064332 748068
=> 我的.cnf:
[mysqld]
max_allowed_packet=268435456
open_files_limit=10000
query_cache_type=1
query_cache_size=768M
query_cache_limit=2048M
sort_buffer_size=4M
join_buffer_size=26M
read_rnd_buffer_size = 1M
max_heap_table_size = 1024M
tmp_table_size = 1024M
table_open_cache = 15000
innodb_log_buffer_size = 64M
max_connections=200
wait_timeout=26000
interactive_timeout=26000
innodb_buffer_pool_size=256M
=> Mysqltuner.pl:
>> MySQLTuner 1.4.0 - Major Hayden <[email protected]>
>> Bug reports, feature requests, and downloads at http://mysqltuner.com/
>> Run with '--help' for additional options and output filtering
[OK] Currently running supported MySQL version 5.6.23
[OK] Operating on 64-bit architecture
-------- Storage Engine Statistics -------------------------------------------
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MRG_MYISAM
[--] Data in MyISAM tables: 3G (Tables: 3156)
[--] Data in InnoDB tables: 183M (Tables: 1455)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 52)
[!!] Total fragmented tables: 5
-------- Security Recommendations -------------------------------------------
[OK] All database users have passwords assigned
-------- Performance Metrics -------------------------------------------------
[--] Up for: 2d 20h 23m 59s (11M q [45.850 qps], 381K conn, TX: 85B, RX: 2B)
[--] Reads / Writes: 82% / 18%
[--] Total buffers: 2.1G global + 31.4M per thread (200 max threads)
[OK] Maximum possible memory usage: 8.2G (27% of installed RAM)
[OK] Slow queries: 0% (4/11M)
[OK] Highest usage of available connections: 7% (14/200)
[OK] Key buffer size / total MyISAM indexes: 8.0M/432.3M
[OK] Key buffer hit rate: 99.6% (493M cached / 1M reads)
[OK] Query cache efficiency: 59.6% (5M cached / 8M selects)
[!!] Query cache prunes per day: 143463
[OK] Sorts requiring temporary tables: 0% (16 temp sorts / 434K sorts)
[!!] Joins performed without indexes: 2610
[!!] Temporary tables created on disk: 83% (458K on disk / 550K total)
[OK] Thread cache hit rate: 99% (36 created / 381K connections)
[!!] Table cache hit rate: 13% (1K open / 12K opened)
[OK] Open file limit used: 1% (324/30K)
[OK] Table locks acquired immediately: 99% (4M immediate / 4M locks)
[!!] Connections aborted: 18%
[OK] InnoDB buffer pool / data size: 256.0M/183.9M
[OK] InnoDB log waits: 0
-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Increasing the query_cache size over 128M may reduce performance
Adjust your join queries to always utilize indexes
Temporary table size is already large - reduce result set size
Reduce your SELECT DISTINCT queries without LIMIT clauses
Increase table_open_cache gradually to avoid file descriptor limits
Read this before increasing table_open_cache over 64: http://bit.ly/1mi7c4C
Your applications are not closing MySQL connections properly
Variables to adjust:
query_cache_size (> 768M) [see warning above]
join_buffer_size (> 26.0M, or always use indexes with joins)
table_open_cache (> 15000)
答案1
mysqltuner 的理念是推荐一些操作来提高性能。优化表会关注碎片。不过,优化大表需要一些时间,而您正在优化的表已被锁定。通常,以 为前缀的警告注释会[!!]
在部分中被注释掉General recommendations
。
在调整 mysql 的默认参数之前,您应该检查您的 sql 语句和 sql 连接。没有索引的连接会导致严重的性能损失。尝试使用来slow_queries
确定要优化哪些查询。
而且结果集的大小通常太大。想象一下带有数据库的商店系统。
例子
假设您的商店系统中有 10,000 件商品,则调用select * from items;
将返回所有 10,000 件商品,因此您的结果集大小为 10,000。但您不太可能真的需要一次性获取所有 10,000 件商品。
SQL 的主要目的实际上是使用过滤器来减少结果集,这些过滤器对索引最有效。例如,您正在搜索所有具有黄色的项目,您可以将结果集大小减少select * from items where color="yellow";
但如果你拥有几百个黄色项目,那么在网页上显示仍然太多。因此,你限制了搜索结果
select * from items where color="yellow" limit 1,10
第一页有 10 个项目
select * from items where color="yellow" limit 11,20
翻到下一页等等...
因此,我建议在调整数据库之前先调整语句,因为如果您修正表索引并限制大型结果集,您将获得更高的性能。这就是 mysqltuner 发出这些警告的原因。
调试连接和索引最有用的工具之一是explain
在选择语句前面使用:
explain select i.name, l.address
from items i
inner join location l on i.location = l.id
where l.description like '%universe%';
将显示用于编译结果的具有和不具有索引的表行数。