[MySQL优化案例]系列 -- 频繁创建临时表

作/译者:叶金荣(Email: email.gif),来源:http://imysql.cn,转载请注明作/译者和出处,并且不能用于商业用途,违者必究。
引言:某客户新上线一个项目,利用存储过程处理用户登录相关事务。在存储过程中,需要对用户数据进行处理,于是他们采用临时表(temporary table)来做这个动作,先创建一个临时表,然后插入数据,处理;由于是采用连接池方式,担心临时表被复用,于是在最后删除该临时表。该客户采用16G的2950机器做mysql db server,利用loadrunner进行模拟登录测试,发现并发量达到2,30万之后,就再也上不去了,而且峰值不是很稳定的处于30多万的级别上。
一开始以为是机器性能达到了极限,经过询问各种状况后,认为应该还可以得到改进和优化。经过现场分析后,发现在测试达到峰值时,会有大量的 "waiting for table",以及大量的 create temporary tabledrop table 的线程在等待。很明显,瓶颈在于频繁的创建和删除临时表,mysql需要频繁的处理打开和关闭表描述符,才会导致了上面的问题。还好他们采用了连接池,否则情况将会更糟糕。建议他们把最后的 drop table 改成 truncate table,把临时表清空了,也就不会担心下一次调用时临时表不为空了,省去了频繁的处理表文件描述符,并发用户数也稳定的保持在了40多万。
附:上面提到的数字,仅作参考,均为该客户自行提供。
本文出自 “MySQL中文网”博客 http://www.imysql.cn/
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值