- 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数据：
- # -*- 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
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;
转播
