为什么这个简单的sql执行这么慢
推荐于2016-10-14
展开全部
到这个数量级的全部更新,肯定会很慢。
第一。你的记录不一定在同一个partition,
第二。不明白为什么那么多人建议你建索引,你建的索引越多,你的更新速度越慢,因为你更新记录的同时,还有更新索引。
第三。你必须知道更新速度慢的瓶颈在哪里。是读写太多,还是内存不够,还是CUP不够快,然后对症下药。
下面介绍两个简单的办法,也许有效:
第一:
把这个100W行的表纵向劈成两个,用外键关系连接,一个装小的,经常改变的数据比如ID,外键,状态值,时间等,另一个装大的,不经常改变的数据,比如很长的字符串,xml,text 等。
这样更新时操作小的这个表,可以大大节约内存和CPU 开销,降低磁盘操作。
坏处就是查询时会慢些。
第二:
把这100W行横向切成很多个表,比如每个月的记录装在一个表里,这样每个表的记录数可能只有几万,查询,更新都会快很多。
坏处是查询,更新都不如原来好写。
第一。你的记录不一定在同一个partition,
第二。不明白为什么那么多人建议你建索引,你建的索引越多,你的更新速度越慢,因为你更新记录的同时,还有更新索引。
第三。你必须知道更新速度慢的瓶颈在哪里。是读写太多,还是内存不够,还是CUP不够快,然后对症下药。
下面介绍两个简单的办法,也许有效:
第一:
把这个100W行的表纵向劈成两个,用外键关系连接,一个装小的,经常改变的数据比如ID,外键,状态值,时间等,另一个装大的,不经常改变的数据,比如很长的字符串,xml,text 等。
这样更新时操作小的这个表,可以大大节约内存和CPU 开销,降低磁盘操作。
坏处就是查询时会慢些。
第二:
把这100W行横向切成很多个表,比如每个月的记录装在一个表里,这样每个表的记录数可能只有几万,查询,更新都会快很多。
坏处是查询,更新都不如原来好写。
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询