长时间处于sending data，巨慢。。。求助

palance

分了256个表，，每张表均有5000多条记录，每张表结构均为

+------------+-------------+------+-----+-------------------+-------+
| Field      | Type        | Null | Key | Default           | Extra |
+------------+-------------+------+-----+-------------------+-------+
| userid     | char(60)    | NO   | PRI |                   |       |
| useridmd5  | char(32)    | NO   |     |                   |       |
| filemd5    | char(32)    | NO   |     |                   |       |
| content    | mediumblob  | NO   |     |                   |       |
| version    | varchar(32) | NO   |     |                   |       |
| lastupdate | timestamp   | NO   | MUL | CURRENT_TIMESTAMP |       |
+------------+-------------+------+-----+-------------------+-------+
其中每条记录的content是一个1M左右的zip文件，其他字段都实际十几个字符的字串。我的机器是8个cpu，4G内存。

我需要每天把userid和lastupdate弄出来一遍，我试过用一个进程跑256次和32个进程同时跑8次，发现总耗时差不多，大概都需要4个多小时，但如果数据库只有一张5000多条记录的表，跑一遍也就是几秒钟。

这是我其中一条sql语句：
select lastupdate, userid into outfile '/tmp/sgim_user25.udidx'  from sgim_user00；

发现长时间处于sending data状态。其实每个表的规模都不大，不应该会这么慢啊，sql语句如此简单，已经没有什么优化余地了。请高人指点一二，有没有什么办法可以优化呢？

kider

也就是说你的数据量笼统计算： 5000×1M×256＝约1280G（每个表5G）。是不？
那如果在这些数据中找东西，看看那里是瓶颈，IO还是其他，找出它，针对性的解决问题。

建议：
把字段顺序调整一下试试， lastupdate, userid 放在前两个。
或者分表，关联表。
或者把这个大字段直接存入OS中，表里只保留链接...

yinshi

大字段直接存入OS中是正道