MySQL 性能问题

Question

在过去的 3 周中，我们的 MySQL 服务器一直存在瓶颈问题。我一直在使用 MonYOG 来查看进程列表，试图了解这些问题。我们知道我们在代码中运行的一些查询和进程没有得到优化，但我并不完全相信这是我们问题的主要来源。我觉得我们的服务器应该能够克服这些问题。

我们的表混合了 innodb 和 myISAM。我绝不是 DBA，也不会假装是 DBA，所以我不确定在我们当前的环境中哪种引擎是最好的。我们的阅读量很大，但也混合了大量更新和插入内容。我看到很多锁定的表，这让我认为 innodb 可能更好，因为它执行行锁而不是表锁。我将我们的一些表从 MyISAM 转换为 innodb 以利用一些可用的设置。开发人员也在使用大量复杂的连接。

这是我们在 my.cnf 中运行的内容：

[mysqld]
datadir=/var/lib/mysql
port=3306
socket=/var/lib/mysql/mysql.sock
user=mysql

key_buffer_size=512M

innodb_file_per_table
innodb_buffer_pool_size=6GB
#the following line is causing some odd errors when doing db dump
#innodb_log_file_size=128M
innodb_log_buffer_size=8M
innodb_additional_mem_pool_size=32M

max_allowed_packet=16M
join_buffer_size=8M
sort_buffer_size=8M
max_connections=500
wait_timeout=500
skip-name-resolve
thread_cache=256
table_cache=256
tmp_table_size=48M
max_heap_table_size=48M

query_cache_size=64M

#logging of slow queries
log-slow-queries=/var/log/mysql-slow-query.log

# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
#old_passwords=1

# Disabling symbolic-links is recommended to prevent assorted security risks;
# to do so, uncomment this line:
# symbolic-links=0

[mysqld_safe]
log-error=/var/log/mysqld.log
#pid-file=/var/run/mysqld/mysqld.pid

上周我将当前的“innodb_buffer_pool_size”更改为 6GB，这大大改善了瓶颈。实际上，我们今天才真正开始再次看到问题。本周交通量有所增加，因为我们学校开学，足球赛季也开始了。

如果需要，我可以提供各种统计信息。我不确定此时还需要提供什么。

如果我无法弄清楚这一点，我将被迫请来顾问。我希望有人能够帮助我处理其中的一些设置。

提前致谢。

- - - - - - - - - 编辑 - - - - - - - - - -

以下是一些额外的信息要求：

MySQL 版本 - 5.0.95
操作系统版本 - CentOS 5.6（将在未来几周内升级到 6.4）

服务器 - Dell PowerEdge R710
CPU - 双四核 2.8GHz
RAM - 12GB
这是一台专用机器。在这个盒子上运行的唯一东西是 MySQL

Answer 1

表锁定MyISAM可能是一个杀手，迁移到InnoDB可能是您可以做的最好的事情之一，以继续提高可扩展性。当然，您对 的更改innodb_buffer_pool_size不会影响不是InnoDB.

然而，一个问题是 MySQL 5.0 中的 InnoDB 版本与后续版本相比仍然相当原始，尤其是在多核机器和内部扩展方面。这在High-Performance MySQL 中进行了详细讨论，上次更新是一年多前，但即使 MySQL 5.6 由于当时的发布状态而以现在时态和未来时态混合进行讨论，它仍然非常有用. 我与这本书或其作者没有任何关系，我只是认为这是一个很好的参考。如果你没有它，我会推荐它，因为它详细说明了该做什么、不该做什么以及为什么。

但是，如果考虑中的系统是我的系统，我会计划至少升级到 MySQL 5.5，可能还有 MySQL 5.6，因为 InnoDB 和其他地方的内部结构都有显着改进。

查看您的配置，当您查看性能问题时，查询缓存总是需要考虑的。较大的缓存可能会有所帮助（可能是 128M 到 256M），但较小或禁用的查询缓存也可能是有益的，因为它确实代表了每个SELECT查询都必须通过的全局阻塞点。适当的设置几乎完全特定于工作负载。

在您的配置中，没有什么是特别次优的，但我想补充一点，如果您想使用您在网上找到的任何调优“脚本”……请尝试抵制这种诱惑。仅“调整”您有特定原因要调整的内容，并且一次只调整一个参数。成功升级后，尝试删除尽可能多的自定义值（除了innodb_buffer_pool_size），并让新版本的行为及其默认值决定需要调整的内容。

跨版本升级时官方推荐的路径始终是从旧版本进行完整的 mysqldump，然后在新安装上恢复，尽管可以进行“二进制”升级，您只需针对旧版本datadir和做mysql_upgrade。官方路径是从 5.0 到 5.1，然后从 5.1 到 5.5。

http://dev.mysql.com/doc/refman/5.1/en/upgrading-from-previous-series.html http://dev.mysql.com/doc/refman/5.5/en/upgrading-from-previous -series.html

有很多东西需要消化，但最重要的是 5.0 已经结束了，一年多来还没有发布那么多错误修复版本......而较新的版本代表了一个大幅改进的产品，不应该需要对您的应用程序进行重大更改。