[转]mysql大表更新sql的优化策略

看了该文章之后，很受启发，mysql在update时，一般也是先select。但注意，在Read Committed隔离级别下，如果没有使用索引，并不会锁住整个表，

还是只锁住满足查询条件的记录而已。使用索引的最佳方式是使用主键，如果我们知道主键的范围（只要是精确范围的超集就可以了），那可以在查询

条件中加上主键的范围，这样查询时，会使用主键索引，就可以提高查询的速度了。这样，我们不用单独再给其它字段加索引，使用已知的索引就可以

加速查询，这种方式感觉很屌。

原文：http://blog.csdn.net/bruce128/article/details/17426671

问题sql背景：项目有6个表的要根据pid字段要写入对应的brand_id字段。但是这个其中有两个表是千万级别的。我的worker运行之后，线上的MySQL主从同步立刻延迟了！运行了一个多小时之后，居然延迟到了40分钟，而且只更新了十几万行数据。问题sql如下：

    UPDATE product
    SET brand_id = [newBrandId]
    WHERE pid = [pid]
        AND brand_id = 0

项目组的mysql专家帮我分析了下，因为pid字段没有索引，mysql引擎要逐行扫描出与传入的pid值相等的列，然后更新数据，也就是要扫描完1000W+行磁盘数据才能执行完这个sql。因为是update操作，没有用到索引，于是导致这个sql会占用表锁，其它的sql只能等这个sql执行完成之后才能开始执行。更严重的是，这个千万级的表里面有多少个不同的pid，我就要执行多少个这样的sql。

同事给我的建议的根据id字段进行sql代码层次的横向分表。每次更新1000行的数据，这样mysql引擎就不用每次在扫全表了，数据库压力是之前的万分之一。而且id作为主键，是有索引的，这个时候占用的是这1000行数据的行级锁，不会影响其它的数据。有索引能大大优化查询性能，优化后的sql如下：

UPDATE product
SET brand_id = [newBrandId]
WHERE pid = [pid]
    AND brand_id = 0
    AND id BETWEEN [startNum] AND [endNum]  

仅仅用了id限区间的语句，将一个千万级的大表代码层次上进行横向切割。重新上线worker后，mysql主从没有任何延迟！而且经过监控，短短10分钟就更新了十几万数据，效率是之前的6倍！更重要的是数据库负载均衡，应用健康运行。