MySQL性能问题

Question

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

我们的表是无害数据库和myISAM的混合。我绝不是一个DBA，也不要假装是DBA，所以我不知道在我们当前的环境中，什么引擎是最好的。我们读起来很重，但也有大量的更新和插入。我看到了很多上锁的表，这让我觉得无害数据库可能更好，因为它是行锁而不是表锁。为了利用一些可用的设置，我将我们的几个表从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 -12 RAM

这是一台专用机器。唯一运行在此框上的是MySQL。

Answer 1

MyISAM上的表锁可能是一个杀手，迁移到InnoDB可能是继续提高可伸缩性的最好方法之一。当然，对innodb_buffer_pool_size的更改不会影响不是InnoDB的表。

但是，一个问题是，与以后的版本相比，InnoDB 5.0中的MySQL版本仍然相当原始，特别是在多核机器和内部扩展方面。这在高性能MySQL中得到了详细的讨论，这是在一年多以前更新的，但是仍然非常有用，尽管由于当时的发布状态，MySQL 5.6是在当前和未来紧张的组合中讨论的。我和这本书或它的作者没有任何联系，我只是觉得这是一个很好的参考。如果你没有它，我会推荐它，因为它涉及到很多细节，关于该做什么，什么不该做，以及为什么。

但是，如果正在考虑的系统是我的系统，我将计划至少升级到MySQL 5.5，并可能升级到MySQL 5.6，因为InnoDB内部以及其他方面都有了很大的改进。

在查看您的配置时，查询缓存在查看性能问题时总是需要考虑的问题。一个更大的缓存可能会有所帮助(也许1.28亿到2.56亿)，但更小的查询缓存或禁用的查询缓存也可能是有益的，因为它确实代表了每个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是在终身制，还没有那么多的补丁发布超过一年.更新的版本代表了一个大大改进的产品，不需要在应用程序中进行重大更改。