MYSQL(通过WAMP)长更新查询时间

时间:2014-09-15 02:49:17

标签: mysql

我花了几周的时间来处理这个问题无济于事,所以我希望你能帮忙。一般来说,我有一个永远运行的更新查询(我已经放弃了12小时后)。为了打破明显的阻碍,我在列上有一个索引。另外,我在MYSQL上完全是自学成才,因此我可能需要对数据/流程等进行额外的澄清。这个数据库仅供我个人使用,离线。换句话说......这不是我的日常工作。虽然我喜欢MYSQL,但我不是超级用户。

首先,我的系统规格......

  • 笔记本电脑三星QX410
  • Windows 7,64位
  • Intel i5,M 480 @ 2.67 GHz
  • RAM:8 GB(7.79可用)
  • WAMP 2.5 with MYSQL v5.6.17
  • 表格是INNODB

MYSQL设置:

' The MySQL server  
[wampmysqld]  
port        = 3306  
socket      = /tmp/mysql.sock  
key_buffer_size = 512M  
max_allowed_packet = 32M  
sort_buffer_size = 512K  
net_buffer_length = 32K  
read_buffer_size = 256K  
read_rnd_buffer_size = 512K  
myisam_sort_buffer_size = 8M  
basedir=c:/wamp/bin/mysql/mysql5.6.17  
log-error=c:/wamp/logs/mysql.log  
datadir=c:/wamp/bin/mysql/mysql5.6.17/data  

' Uncomment the following if you are using InnoDB tables  
innodb_data_home_dir = C:\mysql\data/  
innodb_data_file_path = ibdata1:10M:autoextend  
innodb_log_group_home_dir = C:\mysql\data/  
innodb_log_arch_dir = C:\mysql\data/  
' You can set .._buffer_pool_size up to 50 - 80 %  
' of RAM but beware of setting memory usage too high  
innodb_buffer_pool_size = 4000M  
innodb_additional_mem_pool_size = 32M  
' Set .._log_file_size to 25 % of buffer pool size  
innodb_log_file_size = 512M  
innodb_log_buffer_size = 256M  
innodb_flush_log_at_trx_commit = 0  
innodb_lock_wait_timeout = 50  

更详细的问题:

我有两个表Trade_List和Cusip_Table,我正在尝试填充Trade_List中的一个列(我需要预先填充此值,因为将对其运行许多查询)。

Trade_List有11列,其中两列是相关的。

  • CUSIP(varchar 45) - 通常这是一个9位数的字母数字。

  • TICKER(varchar 45) - 通常这是10个字母或更少。我想填充这个。

此表大约有1000万行 我删除了此表中的所有索引,除了CUSIP上的一个索引。

Cusip_Table有5列,其中两列是相关的。

  • CUSIP(varchar 45) - 通常这是一个9位数的字母数字。

  • TICKER(varchar 45) - 通常这是10个字母或更少。这已经填充了。

此表大约有70,000行 我有一个索引'CTDuplicateCheck'(Cusip,Ticker)。

当我跑...

Select A.cusip, B.ticker  
From Trade_list A, Cusip_table B  
Where A.cusip = B.cusip;  

... MYSQL表示查询大约需要13秒,但实际上它似乎需要大约一分钟,所以我对它进行了分析......

starting                0.000093  
checking permissions    0.000006  
checking permissions    0.000005  
Opening tables          0.000041  
init                    0.000037  
System lock             0.000013  
optimizing              0.000015  
statistics              0.000041  
preparing               0.000030  
executing               0.000002  
Sending data           10.982211  
end                     0.000014  
query end               0.000010  
closing tables          0.000018  
freeing items           0.000070  
logging slow query      0.000004  
cleaning up             0.000019  

我不知道这意味着什么,但发送数据10秒似乎是合理的(返回集约为9M行。

只是为了踢,为了确保索引正常工作,我运行了'解释'(如下所示)。我认为这表明我的索引工作正常。

1   SIMPLE  B   index   CTDuplicateCheck    CTDuplicateCheck    96      53010                        Using where; Using index  
1   SIMPLE  A   ref     TL1Cusip            TL1Cusip            48      13f_master_data.B.CUSIP 154 Using index  

**注意:13f_Master_Data是数据库的名称。

无论如何,当我运行相同的查询,但将其更改为更新时,一切都会崩溃,并且无法完成。我希望事情运行得慢一点,但12小时+?我无法想象这对于触及9M行的更新查询来说是正常的。最初的INSERT花了不到一个小时,选择只需不到一分钟。更新代码如下......

Update Trade_list A, Cusip_table B 
Set A.ticker = B.ticker
Where A.cusip = B.cusip;

我试过的东西:

  • 从Trade_List中删除了几乎所有索引。我在CUSIP上留下了一个。

  • 将RAM从4 GB升级到8 GB。这没什么。经过进一步调查,我的CPU和RAM不是限制因素。 CPU通常占30%左右,RAM永远不会超过5GB。这让我相信问题是I / O.是否可能MYSQL正在进行全表扫描?为什么不利用该指数?

  • 根据http://www.percona.com/blog/2013/09/20/innodb-performance-optimization-basics-updated/https://rtcamp.com/tutorials/mysql/mysqltuner/以及http://www.percona.com/blog/2006/09/29/what-to-tune-in-mysql-server-after-installation/更改了所有类型的内存分配。据我所知,这没有任何作用。同样,我认为限制因素不是可用内存。另外,我毫不怀疑我的内存分配(如上所示)完全被搞砸了。我不知道我在做什么,并改变了所有地方的东西。也就是说,我不认为记忆的变化会让事情变得更糟。

  • 升级的MYSQL和Wamp版本(什么也没做)。

  • 阅读并学习了很多关于索引的知识。坦率地说,我对MYSQL知之甚少,而且我完全是自学成才。我已经在这次尝试中学到了很多关于记忆的知识,但是需要有人介入并告诉我在哪里完全出轨。该数据库用于我自己的离线分析。我是唯一的用户。

我很乐意提供可能有助于分析问题的其他信息。我完全失去了这个。我唯一能想到的是系统正在逐行进行全面扫描......对于每次更新中的查找。但是,这可能是完全错误的。

非常感谢您的想法。 PM

0 个答案:

没有答案