MySQL报告数据库的性能很慢

目前我有3台服务器在运行，2台远程服务器在运行MySQL 5.5.24，备份服务器在运行MySQL 5.1.63，1台本地服务器在运行MySQL 5.5.20。主服务器用于报告目的；目前有144个表（

MyISAM

和

InnoDB

），大约80gb的数据，较大的表每个表大约有1300万行

在远程服务器上，我通过webmin的访问权限非常有限，因此我无法直接进行更改，我需要向IT部门请求更改

自从上个月MySQL崩溃以来，我在主服务器上遇到了一些严重的性能问题。服务器运行的开发版本存在一些磁盘写入错误，在恢复后，我们安装了

MySQL 5.5.23

版本，这时性能问题开始出现。我们最近安装了

MySQL 5.5.24

（最新稳定版本），但仍然存在性能问题

以下是服务器配置，均为专用服务器：

Main：

Operating system: Gentoo Linux
Kernel and CPU: Linux 2.6.31-gentoo-r6 on x86_64 
Processor information: Intel(R) Xeon(TM) CPU 2.66GHz, 8 cores
Real memory (ram): 23.55 GB total
Virtual memory: 3.74 GB total
Local disk space: 463.38 GB total (about 30% free)

Operating system: Gentoo Linux
Kernel and CPU: Linux 2.6.31-gentoo-r6 on x86_64
Processor information: Intel(R) Core(TM)2 Duo CPU E6405 @ 2.13GHz, 2 cores
Real memory (ram): 15.68 GB total
Virtual memory: 16.01 GB total
Local disk space: 4.73 TB total (about 80% free)

Operating system: Ubuntu Linux 9.04
Kernel and CPU: Linux 2.6.32-33-server on x86_64
Processor information: Intel(R) Core(TM)2 Duo CPU E6550  @ 2.33GHz, 2 cores
Real memory (ram): 1.95 GB total
Virtual memory: 5.65 GB total
Local disk space: 141.15 GB total (about 5% free)

备份：

Operating system: Gentoo Linux
Kernel and CPU: Linux 2.6.31-gentoo-r6 on x86_64 
Processor information: Intel(R) Xeon(TM) CPU 2.66GHz, 8 cores
Real memory (ram): 23.55 GB total
Virtual memory: 3.74 GB total
Local disk space: 463.38 GB total (about 30% free)

Operating system: Gentoo Linux
Kernel and CPU: Linux 2.6.31-gentoo-r6 on x86_64
Processor information: Intel(R) Core(TM)2 Duo CPU E6405 @ 2.13GHz, 2 cores
Real memory (ram): 15.68 GB total
Virtual memory: 16.01 GB total
Local disk space: 4.73 TB total (about 80% free)

Operating system: Ubuntu Linux 9.04
Kernel and CPU: Linux 2.6.32-33-server on x86_64
Processor information: Intel(R) Core(TM)2 Duo CPU E6550  @ 2.33GHz, 2 cores
Real memory (ram): 1.95 GB total
Virtual memory: 5.65 GB total
Local disk space: 141.15 GB total (about 5% free)

发展：

Operating system: Gentoo Linux
Kernel and CPU: Linux 2.6.31-gentoo-r6 on x86_64 
Processor information: Intel(R) Xeon(TM) CPU 2.66GHz, 8 cores
Real memory (ram): 23.55 GB total
Virtual memory: 3.74 GB total
Local disk space: 463.38 GB total (about 30% free)

Operating system: Gentoo Linux
Kernel and CPU: Linux 2.6.31-gentoo-r6 on x86_64
Processor information: Intel(R) Core(TM)2 Duo CPU E6405 @ 2.13GHz, 2 cores
Real memory (ram): 15.68 GB total
Virtual memory: 16.01 GB total
Local disk space: 4.73 TB total (about 80% free)

Operating system: Ubuntu Linux 9.04
Kernel and CPU: Linux 2.6.32-33-server on x86_64
Processor information: Intel(R) Core(TM)2 Duo CPU E6550  @ 2.33GHz, 2 cores
Real memory (ram): 1.95 GB total
Virtual memory: 5.65 GB total
Local disk space: 141.15 GB total (about 5% free)

除了

innodb\u buffer\u pool\u size

my.cnf

[mysqld]
back_log = 50
max_connections = 100
max_connect_errors = 10
table_open_cache = 2048
max_allowed_packet = 16M
binlog_cache_size = 1M
max_heap_table_size = 64M
read_buffer_size = 2M
read_rnd_buffer_size = 16M
sort_buffer_size = 8M
join_buffer_size = 8M
thread_cache_size = 8
thread_concurrency = 8
query_cache_size = 64M
query_cache_limit = 2M
ft_min_word_len = 4
default-storage-engine = MYISAM
thread_stack = 262K
stored_program_cache= 1024
transaction_isolation = REPEATABLE-READ
tmp_table_size = 64M
binlog_format=mixed
slow_query_log
long_query_time = 2
key_buffer_size = 512M
bulk_insert_buffer_size = 64M
myisam_sort_buffer_size = 128M
myisam_max_sort_file_size = 10G
myisam_repair_threads = 1
myisam_recover
innodb_additional_mem_pool_size = 16M
innodb_buffer_pool_size = 8G
innodb_data_file_path = ibdata1:10M:autoextend
innodb_write_io_threads = 8
innodb_read_io_threads = 8
innodb_thread_concurrency = 16
innodb_flush_log_at_trx_commit = 1
innodb_log_buffer_size = 8M
innodb_log_file_size = 256M
innodb_log_files_in_group = 3
innodb_max_dirty_pages_pct = 90
innodb_lock_wait_timeout = 240
server-id = 1
event_scheduler = 1
[mysqldump]
quick
max_allowed_packet = 16M
[mysql]
no-auto-rehash
[myisamchk]
key_buffer_size = 512M
sort_buffer_size = 512M
read_buffer = 8M
write_buffer = 8M
[mysqlhotcopy]
interactive-timeout
[mysqld_safe]
open-files-limit = 8192

我尝试过几个大型

存储过程，其中包含大量列和数据，备份服务器的速度大约是主服务器的10倍，在开发服务器上运行它们的速度大约是主服务器的5倍

由于主服务器和备份服务器位于同一远程位置，并且通过VPN，我知道没有连接速度问题

我无法发布
存储过程
代码，但我知道问题在于最终的
选择
，因为所有临时表的创建都非常快，我可以在MySQL监视器（使用
显示完整进程列表
）中看到
选择
占用了95%的时间。大多数
存储过程
都可以处理大量数据，并进行多次连接

你知道为什么主服务器即使是最强大的，也会有如此糟糕的性能吗

我们一直在寻找报告的最新版本的性能缺陷，但我们发现的根本没有帮助

我真的很感激任何帮助

在服务器故障时问这个问题更好吗？这是我的第一个问题

对不起，我的英语有问题。
您尝试的存储过程中所有有问题的SELECT语句都涉及相同的表吗？也许需要在其中一些数据库上重建索引统计信息-查看命令。
最后，我们将数据库移动到另一台服务器，新版本的MySQL
是什么导致了MySQL崩溃？问题是否已完全纠正？例如，如果是部分磁盘故障，而故障磁盘仍在使用，则可能会导致非常差的I/O性能。请尝试您的查询，以查看MySQL在其处理过程中所花费的时间。这个问题可能更适合于或；投票决定移动。数据库是否因磁盘问题而损坏？恢复和表优化后是否运行mysqlcheck。主服务器是否处于负载状态？@eggyal崩溃是由MySQL开发版本错误引起的，这就是为什么我们切换到稳定版本，据我所知，磁盘仍在使用中。我现在正在分析查询@MichaelN数据库是从崩溃之前的
.sql
备份文件中恢复的@Marcus Adams服务器是专用的，没有比平常更多的负载。感谢所有数据库在崩溃之前从.sql备份文件中恢复，我将尝试优化