mysql千万级数据update怎么优化

提问：何设计或优化千万级别表外其信息觉题点范简单说该何做于存储设计必须考虑业务特点收集信息：

1.数据容量：1-3内概少条数据每条数据概少字节；

2.数据项：否字段些字段值否经更新；

3.数据查询SQL条件：哪些数据项列名称经现WHERE、GROUP BY、ORDER BY句等；

4.数据更新类SQL条件：少列经现UPDATE或DELETE WHERE句；

5.SQL量统计比：SELECT：UPDATE+DELETE：INSERT=少

6.预计表及相关联SQL每总执行量何数量级

7.表数据：更新主业务 查询主业务

8.打算采用数据库物理服务器及数据库服务器架构

9.并发何

10.存储引擎选择InnoDBMyISAM

致明白10问题至于何设计类表应该都清楚

至于优化若指创建表能变表结构建议InnoDB引擎利用点内存减轻磁盘IO负载IO往往数据库服务器瓶颈

另外优化索引结构解决性能问题建议优先考虑修改类SQL语句使更快些已靠索引组织结构式前提 索引已经创建非若读主考虑打query_cache 及调整些参数值：sort_buffer_size,read_buffer_size,read_rnd_buffer_size,join_buffer_siz

更信息参见：

MySQL数据库服务器端核参数详解推荐配置

纸谈兵说我思路及我解决抛砖引玉

我近解决问题

我现公司三张表5亿数据每张表每增量100w

每张表概10columns左右

面我做测试比

1.首先看engine,数据量情况没做区情况

mysiam比innodb读情况效率要高13％左右

2.做partition读mysql官文档其实于partition专门myisam做优化于innodb所数据存ibdata面所即使看schema变其实没本质变化

区于同physical disk面情况提升概1％

区同physical disk我三同disks提升概3％其实所谓吞吐量由素决定比explain parition候看record区每区都其实本质没解决读问题提升写效率

另外问题于区张表三column都经用于做查询条件其实件悲惨事情没办所sql做针性区mysql官文档说间做区且用间查询恭喜

3.表主要用读写其实问题充应该问写入候同并发查询我问题比较简单mongodb shredding支持能crushmysql所通情况9am－9pm写入情况候我做 viewview基于近插入或者经查询通做view离读取说写table读进行逻辑判断前view *** 作

4做些archive table比先些表做已统计析通已析＋增量解决

5用mysiam问题要注意.configure候加max index length参数候record数于制定度候indexdisable

这种情况我以前也碰见过，一般的数据库都搞不定，几千万的数据，在进行比较并更新插入数据，得很大的临时表空间和数据库日志文件，我是用load搞定的，

创建一个临时表，用load cursor做，

第一优化你的sql和索引；

第二加缓存，memcached,redis；

第三以上都做了后，还是慢，就做主从复制或主主复制，读写分离，可以在应用层做，效率高，也可以用三方工具，第三方工具推荐360的atlas,其它的要么效率不高，要么没人维护；

第四如果以上都做了还是慢，不要想着去做切分，mysql自带分区表，先试试这个，对你的应用是透明的，无需更改代码,但是sql语句是需要针对分区表做优化的，sql条件中要带上分区条件的列，从而使查询定位到少量的分区上，否则就会扫描全部分区，另外分区表还有一些坑，在这里就不多说了；

第五如果以上都做了，那就先做垂直拆分，其实就是根据你模块的耦合度，将一个大的系统分为多个小的系统，也就是分布式系统；

第六才是水平切分，针对数据量大的表，这一步最麻烦，最能考验技术水平，要选择一个合理的sharding key,为了有好的查询效率，表结构也要改动，做一定的冗余，应用也要改，sql中尽量带sharding key，将数据定位到限定的表上去查，而不是扫描全部的表；

mysql数据库一般都是按照这个步骤去演化的，成本也是由低到高。

---