我有很大的问题试图调整我的MySQL服务器。 在下午五点到六点之间买了电视广告后，我在网站上预计会有很多人在这个时候在网站上有300多人。 我在my.cnf中尝试了很多调整，但是每天晚上都变得越来越糟……我真的很感谢一些帮助，想知道我的问题在哪里..我目前的基础设施如下：
一个服务器为我的网站
一个服务器为我的数据库
这是我目前的configurationmy.cnf：
innodb_file_per_table = 1 innodb_buffer_pool_instances = 13 innodb_buffer_pool_size = 13375M innodb_open_files = 300 innodb_thread_concurrency = 0 #innodb_read_io_threads = 8 #innodb_write_io_threads = 8 #innodb_flush_method = O_DIRECT #join_buffer_size = 30M #sort_buffer_size = 10M #read_buffer_size = 10M wait_timeout = 180 interactive_timeout = 180 max_connections = 250 max_heap_table_size = 256M tmp_table_size = 256M table_cache = 20000 table_definition_cache = 20000 #table_open_cache = 20000 query_cache_type = 0 和mysqltuner结果：
>> MySQLTuner 1.6.9 - Major Hayden <[email protected]> >> Bug reports, feature requests, and downloads at http://mysqltuner.com/ >> Run with '--help' for additional options and output filtering [--] Performing tests on 127.0.0.1:3306 [OK] Logged in using credentials passed on the command line [--] Skipped version check for MySQLTuner script [OK] Currently running supported MySQL version 5.5.38-0+wheezy1-log [OK] Operating on 64-bit architecture -------- Storage Engine Statistics ----------------------------------------------------------------- [--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MEMORY +MRG_MYISAM +MyISAM +PERFORMANCE_SCHEMA [--] Data in MyISAM tables: 32M (Tables: 126) [--] Data in InnoDB tables: 10G (Tables: 1503) [!!] Total fragmented tables: 359 -------- Performance Metrics ----------------------------------------------------------------------- [--] Up for: 1m 59s (82K q [695.832 qps], 335 conn, TX: 538M, RX: 34M) [--] Reads / Writes: 99% / 1% [--] Binary logging is disabled [--] Total buffers: 13.8G global + 2.7M per thread (300 max threads) [--] P_S Max memory usage: 0B [--] Galera GCache Max memory usage: 0B [OK] Maximum reached memory usage: 13.9G (44.07% of installed RAM) [OK] Maximum possible memory usage: 14.6G (46.49% of installed RAM) [OK] Slow queries: 0% (1/82K) [OK] Highest usage of available connections: 3% (11/300) [OK] Aborted connections: 0.60% (2/335) [OK] Query cache is disabled by default due to mutex contention. [OK] Sorts requiring temporary tables: 0% (0 temp sorts / 14K sorts) [!!] Joins performed without indexes: 131 [OK] Temporary tables created on disk: 5% (927 on disk / 17K total) [OK] Thread cache hit rate: 96% (11 created / 335 connections) [OK] Table cache hit rate: 25% (1K open / 6K opened) [OK] Open file limit used: 0% (301/40K) [OK] Table locks acquired immediately: 100% (221K immediate / 221K locks) -------- ThreadPool Metrics ------------------------------------------------------------------------ [--] ThreadPool stat is disabled. -------- Performance schema ------------------------------------------------------------------------ [--] Performance schema is disabled. [--] Memory used by P_S: 0B -------- MyISAM Metrics ---------------------------------------------------------------------------- [!!] Key buffer used: 18.2% (763K used / 4M cache) [OK] Key buffer size / total MyISAM indexes: 4.0M/10.6M [OK] Read Key buffer hit rate: 100.0% (562K cached / 0 reads) [OK] Write Key buffer hit rate: 100.0% (14K cached / 0 writes) -------- AriaDB Metrics ---------------------------------------------------------------------------- [--] AriaDB is disabled. -------- InnoDB Metrics ---------------------------------------------------------------------------- [--] InnoDB is enabled. [OK] InnoDB buffer pool / data size: 13.1G/10.7G [OK] InnoDB buffer pool instances: 13 [!!] InnoDB Used buffer: 5.30% (45409 used/ 855985 total) [OK] InnoDB Read buffer efficiency: 99.95% (85810161 hits/ 85850600 total) [!!] InnoDB Write Log efficiency: 61.42% (519 hits/ 845 total) [OK] InnoDB log waits: 0.00% (0 waits / 326 writes) -------- TokuDB Metrics ---------------------------------------------------------------------------- [--] TokuDB is disabled. -------- Galera Metrics ---------------------------------------------------------------------------- [--] Galera is disabled. -------- Replication Metrics ----------------------------------------------------------------------- [--] Galera Synchronous replication: NO [--] No replication slave(s) for this server. [--] This is a standalone server. -------- Recommendations --------------------------------------------------------------------------- General recommendations: Run OPTIMIZE TABLE to defragment tables for better performance MySQL started within last 24 hours - recommendations may be inaccurate Adjust your join queries to always utilize indexes Variables to adjust: join_buffer_size (> 128.0K, or always use indexes with joins)
几秒钟之后，人们在网站上的CPU负载相当低（介于1和4之间）。 更糟糕的是，当很多人同时进来，CPU负载为40或50，这是一个问题，我不明白哪个参数，我可以佐以避免这一点。
RAM：我认为RAM在这里足够了。 该服务器有32GB，甚至在网站上有更多的人时不会使用。 它在15-20％，不会在白天移动..我不明白为什么内存不动，我的目标是最大限度地将我的查询内存，以避免击中磁盘。
在高峰时期，这里是free -m ：
total used free shared buffers cached Mem: 32202 25261 6940 0 917 18794 -/+ buffers/cache: 5549 26652 Swap: 1532 21 1511
我正在使用Prestashop作为我的网站，而且我有一个非常大的表格。我将在这个周末对其中一大部分进行归档和截断。 例如 ：
SELECT COUNT(*) FROM ps_connections; => 1 330 373 SELECT COUNT(*) FROM ps_guest; => 6 970 248
如果你有一些build议，这将是伟大的！ 谢谢Julien
注意：对不起，我的英语不好
虽然全面分析是一项复杂而艰巨的任务，但我可以从您提供的信息和调谐器中的警告中提出几个方面的build议。
1）你有32GB内存，但在专用机器上只使用14GB的MySQL。 为什么不给它更多？ build议在专用主机（innodb_buffer_pool_size）上MySQL使用RAM的75％，但是您应该首先检查top，vmstat或任何长期监视，以确保有其他服务的空间或偶尔的事件（如备份）。 注意Linux总是看起来像是“内存不足”，因为它会dynamic地使用任何备用RAM来存放缓冲区和caching – 就像你的例子所显示的那样。
2）innodb_flush_method是一个很大的性能因素，你的设置被注释掉了，所以我不知道实际的（默认）值。 检查服务器variables，看看它是什么。 但是，如果发生停电，改变它对你的诚信有很大的影响。
3）你有很多碎片表。 这可能会导致性能损失 – 如果它们高度分散的话。 还有很多其他文章[1]讨论了如何分割表格，以及是否需要碎片整理，但是对于不同的存储引擎和每个文件表格，它又有点复杂。要对它们进行碎片整理，可以使用优化，或者修改重build表（当然，这些将locking表，所以你需要通过练习或安排停机确保快速）。
1 [ 如何查找和修复零碎的MySQL表
4）“加盟没有指标” – 这可能是你最大的问题，虽然131听起来不是很高。
任何不能/不能使用索引的查询都必须检查每个logging（表扫描），对于较大的表格来说是慢的。 如果您没有自己编写查询（即使用此Pretashop产品），则可能无法在此方面进行工作。
但是，要解决这个问题，您需要查找查询，分析查询，然后相应地添加索引。 为了find查询，我会从慢查询日志开始：你没有很多慢查询，所以我猜测慢阈值设置得太高了？ 所以，如果你可以降低这个，那么开始慢慢查询并分析它们。 使用EXPLAIN命令你应该可以看到JOIN是如何缺less索引的（尽pipe理解EXPLAIN是另一个话题）。 然后添加索引是直接的，但也有其优点和缺点（例如，插入可能运行速度较慢，索引太多会对性能产生不利影响），再加上索引过程将locking表一段时间。
缓冲区度量也存在一些问题，但这是目前超出我的知识的（这就是我提出的这个问题 – 我有相同的写日志效率问题，我不明白）。