mysql update的优化案例
2017-06-07 20:10
525 查看
1.今天接到开发人员 :mysql update 50w和30w的表关联慢,等了2小时也没有出来
mysql> UPDATE DIM_DEVICE_WIR_E_UTRANCELL_F a, temp_vipcell b SET a.vip_bts=b.vip_bts where a.cgi=b.cgi;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
2.那么我的处理方案
先看关联的数据cgi是否有重复,基数有多大? 言外之意-->适合建索引吗,查询,更新,就是减少io,减少数据扫描的块,避免笛卡尔积等
3.OK
那肯定适合建立索引
4.查看索引
show index from 2 个表
no rows ;
无索引
5.建立索引
所以create index idx_xxxx_01 on 表1(cgi);
卡了5分钟,察。。。
6.不对,再慢也得有响应啊
于是怀疑锁表
mysql> show processlist 默认100行,哇塞,太多
7.show processlist where info like '*xx表*' ;
报错
8. show prcoesslist 应该是默认列100个,并且不支持带参数
show full processlist; --列出全部进程信息
9.查询某个表被锁,应该是这样
mysql>SELECT id,user, host, time, command,info FROM information_schema.processlist WHERE state IS NOT NULL and info like '%xxx表%';
mysql>kill id号;
10.我们打算用10000条做测试, 如果不行,我们就1w一次
mysql> create table temp_vipcell_2 as select * from temp_vipcell limit 10000;
Query OK, 10000 rows affected (0.26 sec)
Records: 10000 Duplicates: 0 Warnings: 0
11.更新试试,4秒搞定50w+1w的更新,按理推算,34w应该是34秒搞定。
mysql> UPDATE DIM_DEVICE_WIR_E_UTRANCELL_F a, temp_vipcell_2 b SET a.vip_bts=b.vip_bts where a.cgi=b.cgi;
Query OK, 0 rows affected (4.13 sec)
Rows matched: 10000 Changed: 0 Warnings: 0
12.我们在主表建立索引,果然和推算一样34秒
mysql> create index idx_dim_device_wir_e_001 on DIM_DEVICE_W (cgi);
Query OK, 0 rows affected (2.26 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> UPDATE DIM_DEVICE_W a, temp_vipcell_2 b SET a.vip_bts=b.vip_bts where a.cgi=b.cgi;
Query OK, 0 rows affected (4.13 sec)
Rows matched: 10000 Changed: 0 Warnings: 0
mysql> UPDATE DIM_DEVICE_W a, temp_vipcell b SET a.vip_bts=b.vip_bts where a.cgi=b.cgi;
Query OK, 331262 rows affected (34.84 sec)
Rows matched: 341262 Changed: 331262 Warnings: 0
13.算了不折腾,一晚一次,34秒够了。
别想歪了,兄弟们。
数据库的东西是越快越好, 而某些东西是越慢越好
mysql> UPDATE DIM_DEVICE_WIR_E_UTRANCELL_F a, temp_vipcell b SET a.vip_bts=b.vip_bts where a.cgi=b.cgi;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
2.那么我的处理方案
先看关联的数据cgi是否有重复,基数有多大? 言外之意-->适合建索引吗,查询,更新,就是减少io,减少数据扫描的块,避免笛卡尔积等
3.OK
那肯定适合建立索引
4.查看索引
show index from 2 个表
no rows ;
无索引
5.建立索引
所以create index idx_xxxx_01 on 表1(cgi);
卡了5分钟,察。。。
6.不对,再慢也得有响应啊
于是怀疑锁表
mysql> show processlist 默认100行,哇塞,太多
7.show processlist where info like '*xx表*' ;
报错
8. show prcoesslist 应该是默认列100个,并且不支持带参数
show full processlist; --列出全部进程信息
9.查询某个表被锁,应该是这样
mysql>SELECT id,user, host, time, command,info FROM information_schema.processlist WHERE state IS NOT NULL and info like '%xxx表%';
mysql>kill id号;
10.我们打算用10000条做测试, 如果不行,我们就1w一次
mysql> create table temp_vipcell_2 as select * from temp_vipcell limit 10000;
Query OK, 10000 rows affected (0.26 sec)
Records: 10000 Duplicates: 0 Warnings: 0
mysql> create index idx_temp_01 on temp_vipcell_2 (cgi); Query OK, 0 rows affected (0.04 sec) Records: 0 Duplicates: 0 Warnings: 0 mysql> show index from temp_vipcell_2; +----------------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | +----------------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ | temp_vipcell_2 | 1 | idx_temp_01 | 1 | cgi | A | 9985 | NULL | NULL | | BTREE | | | +----------------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ 1 row in set (0.00 sec)
11.更新试试,4秒搞定50w+1w的更新,按理推算,34w应该是34秒搞定。
mysql> UPDATE DIM_DEVICE_WIR_E_UTRANCELL_F a, temp_vipcell_2 b SET a.vip_bts=b.vip_bts where a.cgi=b.cgi;
Query OK, 0 rows affected (4.13 sec)
Rows matched: 10000 Changed: 0 Warnings: 0
12.我们在主表建立索引,果然和推算一样34秒
mysql> create index idx_dim_device_wir_e_001 on DIM_DEVICE_W (cgi);
Query OK, 0 rows affected (2.26 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> UPDATE DIM_DEVICE_W a, temp_vipcell_2 b SET a.vip_bts=b.vip_bts where a.cgi=b.cgi;
Query OK, 0 rows affected (4.13 sec)
Rows matched: 10000 Changed: 0 Warnings: 0
mysql> UPDATE DIM_DEVICE_W a, temp_vipcell b SET a.vip_bts=b.vip_bts where a.cgi=b.cgi;
Query OK, 331262 rows affected (34.84 sec)
Rows matched: 341262 Changed: 331262 Warnings: 0
13.算了不折腾,一晚一次,34秒够了。
别想歪了,兄弟们。
数据库的东西是越快越好, 而某些东西是越慢越好
相关文章推荐
- [MySQL优化案例]系列 -- 在5.1的分区功能中混用InnoDB和MyISAM
- 【MySQL性能优化】MySQL分库分表与水平分割取模案例(三)
- Mysql性能优化案例 - 覆盖索引分享
- mysql无法优化的sql案例
- 一个mysql索引顺序优化的案例
- mysql 两个表索引优化案例
- MySQL NOT EXISTS优化的一个案例
- [MySQL优化案例]系列 -- 用TIMESTAMP类型取代INT和DATETIME
- [MySQL优化案例]系列 — slave延迟很大优化方法
- mysql优化之insert/delete/update
- [MySQL优化案例]系列 — RAND()优化
- MySQL 传统复制中常见故障处理和结构优化案例分析
- [MySQL优化案例]系列 -- 取出超大结果集的技巧
- [MySQL优化案例]系列 ― 典型性索引引发CPU负载飙升问题
- [MySQL优化案例]系列 — 分页优化
- MYSQL LEFT JOIN连接优化案例一则
- MySQL索引优化案例
- update优化案例
- 一个mysql索引顺序优化的案例
- MySQL的id关联和索引使用的实际优化案例