关于SELECT巨慢的问题

Question

本人MySQL纯新手. 从安装到现在不到一个月的时间还.情况是这样的.
环境是一个MySQL cluster
2个笔记本
一个T61装了   Client + Data node + ndb_mgm + ndb_mgmd + SQL Node
另一个T43装的 Client + Data node
环境都是Red Hat Enterprise Linux 5 (Linux 2.6.18-128.el5). 
CLUSTER版本是5.1.39-ndb-7.0.9-cluster-gpl-logconfig.ini是
Diskless = 1
DataMemory = 1500M
IndexMemory = 32M本意是先拿两个破烂机器试试性能, 顺便也试试看看对于不同的data model哪个性能好.
谁知道一跑出来的结果让我很是那啥...程序时用C API写的.
也是在T61上运行的. 64个thread同时发起连接到localhost 每个线程负责10000个用户. 总数为640000.表结构:
CREATE TABLE SUBSCRIBER ( 
  ID1 BINARY(9), 
  ID2 BINARY(11) NOT NULL, 
  ID3 BINARY(4),
  ID4 BINARY(4),
  ID5 BINARY(4),
  ID6 BINARY(8) NOT NULL,
  DATA VARBINARY(1936) NOT NULL,  CONSTRAINT PRIMARY KEY USING HASH (ID1),
  INDEX USING BTREE (ID2),
  INDEX USING BTREE (ID3),
  INDEX USING BTREE (ID4),
  INDEX USING BTREE (ID5),
  INDEX USING BTREE (ID6)
)
ENGINE = NDBCLUSTER;首先是insert. 表现还算良好. 跑下来一共用了126.56秒. 算算TPS应该是 5000多
接下来就是万恶的select了. 语句是 SELECT 数据 FROM 表名 WHERE ID = 循环的数
一共用时是674.422秒. 比insert慢了6倍. 本以为它就是读东西慢么.
可没曾想接下来的update给了我一个响亮的耳光. 也是根据ID来循环然后UPDATE每一个的DATA值. 结果人家跑下来也就哦呢改了127.12秒. 跟insert不相上下.按理说不应该啊. 我建INDEX就是为了select容易啊. 可没曾想select居然这么不争气.请问各位是不是我的设置和配置哪里出了什么低级问题?
麻烦大家给予指教~万分感谢~

Answer 1

居然问题自己就好了...现在一下从674.422秒提高到了56.5664了..我感觉我没干啥啊..就是小改了一下my.cnf
学着网上别人的样子加了一个slow log想用来debug一下.估计是cluster看到我想看slow log害怕了~自己将功赎罪就把速度提上来了~~总之很好很强大~感谢耶稣他妈的基督啊!

Answer 2

提供一下你的SELECT语句和show index 信息以供分析。