step1,一个简单的联系人表

Java代码

CREATE TABLE `contact784` (
`cid` bigint AUTO_INCREMENT NOT NULL,
`uid` bigint NOT NULL,
`email` varchar(128) NOT NULL,
`name` varchar(64) NOT NULL,
`mobile` varchar(16) NULL,
`atime` timestamp NULL,
`type` enum('BLACK','WHITE','NORMAL') NOT NULl default 'NORMAL',
`info` text NULL,
`memo` varchar(1024) NULL,
PRIMARY key(`cid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT = 100;
ALTER TABLE `contact784` ADD UNIQUE INDEX uniq_uid_email(`uid`,`email`);

step2,插入了100W数据：

Java代码

# -*- coding: utf-8 -*-
#@author python.han@gmail.com
import MySQLdb
import random
import string
import threading
import time
domains = ['org','com.cn','qq.com','yahoo.com','163.com','com','cn','sina.cn','sina.com']
host = "localhost"
user = "xx"
pwd = "xx"
db = "t3"
def getRandomValue():
email = ""
s = ""
for x in range(random.randint(1,10)):
s += random.choice(string.letters)
b = list(s)
domain = ''.join(b)+"."+random.choice(domains)
email = s+"@"+domain
return email,s
def insert(count):
conn=MySQLdb.connect(host=host,user=user,passwd=pwd,db=db)
cursor=conn.cursor()
for cid in xrange(count):
uid = random.randint(1000000000,9999999999)
email,name = getRandomValue()
sql = "insert into contact784(uid,email,name) values (%d,'%s', '%s')" %(uid,email,name)
n=cursor.execute(sql)
cursor.close()
conn.commit ()
conn.close()
if __name__=='__main__':
start = time.clock()
for i in range(100):
worker = threading.Thread(target = insert(10000))
worker.start()
end = time.clock()
print "elsaped:%s" %(end-start)

step3,要重新单线程插入，需要把数据清空.
因为python多线程由于GIL的关系，实际上上面的100个线程只产生了一个连接，需要测试一下纯单线程插入是不是要快些:)

执行：delete from contact784
半小时没有执行完毕！

诊断方式：
1，iostat ，top等查看磁盘io很大
2，inotifywatch发现io的事件非常多

原因：在大表上使用delete from 清空一个表是非常慢的。因为InnoDB必须处理表中的每一行，根据InnoDB的事务设计原则，首先需要把“删除动作”写入“事务日志”，然后写入实际的表。所以，清空大表的时候，最好直接drop table然后重建。
注:
在delete from 执行的过程中：
用：select count(*) from contact784;发现表的数据量一直是100行
用:explain select count(*) from contact784;可以发现数量一直在减少，显示当前

784是是因为前面这个文章的原因“
http://hanyh.iteye.com/blog/431323

我从oracle undo的角度来回答哈：
delete是个极其昂贵的操作哦，它会产生大量的undo数据（最多的），你每删一次oracle都要记录一次。
如果从undo角度来看的话，可以优化的就是控制事务的长度，即用：commit。

一次delete速度异常慢的处理过程

转自：http://space.itpub.net/10710960/viewspace-610982

一次小数据量删除，但花费2个小时还没完成的问题

delete from TOPBOX_COURSEWARE where id like '760%';
花费非常长的时间，topbox_courseware表大概2w数据，要删除的也就2500条数据。
问题原因：
由于TOPBOX_COURSEWARE表与多个表有外键关联，而且关联的表中有2张千万级别的大表。
通过v$session_wait,v$session表

select * from v$session_wait a,v$session b
where b.sid=a.sid
and a.event not like 'SQL*Net%';

发现该session的event是db file scattered read。
这个事件一般是表示法伤了全表扫描相关的等待。通常意味着全表扫描过多，或者I/O能力不足，或是I/O争用造成的。

解决方法：
1.通过dba_constraints表找到topbox_courseware表对应的约束
select * from dba_constraints where constraint_type='R' and wner='TOPBOX' and r_constraint_name='PK_TOPBOX_COURSEWARE'
得到两个外键约束名
FK_TOPBOX_COURSCO_REF_COUR
FK_TOPBOX_CSTUDY_REF_COUSE

2.通过命令将这2个约束disable
alter table topbox_coursescore disable constraint fk_topbox_coursco_ref_cour;
alter table topbox_coursestudy disable constraint fk_topbox_cstudy_ref_couse;

通过上面的处理delete只需要不到1秒的时间

3.将约束重新激活
由于topbox_coursescore，topbox_coursestudy是千万级的大表，如果直接enable而不加其他参数，启用约束后，oracle会对表中数据
逐条检查，所以速度会非常慢。而且已经插入的数据没有脏数据，所以为了避免不必要的工作，就要使用novalidate
alter table topbox_coursescore enable novalidate constraint fk_topbox_coursco_ref_cour;
alter table topbox_coursestudy enable novalidate constraint fk_topbox_cstudy_ref_couse;

一次delete速度异常慢的处理过程

InnoDB delete from xxx速度暴慢原因

一次delete速度异常慢的处理过程