如何设计或优化千万级别的大表？此外无其他信息，个人觉得这个话题有点范，就只好简单说下该如何做，对于一个存储设计，必须考虑业务特点，收集的信息如下
文章源自很文博客https://www.hinwi.com/很文博客-https://www.hinwi.com/12484.html
1.数据的容量：1-3年内会大概多少条数据，每条数据大概多少字节；文章源自很文博客https://www.hinwi.com/很文博客-https://www.hinwi.com/12484.html
2.数据项：是否有大字段，那些字段的值是否经常被更新；文章源自很文博客https://www.hinwi.com/很文博客-https://www.hinwi.com/12484.html
3.数据查询SQL条件：哪些数据项的列名称经常出现在WHERE、GROUP BY、ORDER BY子句中等；文章源自很文博客https://www.hinwi.com/很文博客-https://www.hinwi.com/12484.html
4.数据更新类SQL条件：有多少列经常出现UPDATE或DELETE 的WHERE子句中；文章源自很文博客https://www.hinwi.com/很文博客-https://www.hinwi.com/12484.html
5.SQL量的统计比，如：SELECT：UPDATE+DELETE：INSERT=多少？文章源自很文博客https://www.hinwi.com/很文博客-https://www.hinwi.com/12484.html
6.预计大表及相关联的SQL，每天总的执行量在何数量级？文章源自很文博客https://www.hinwi.com/很文博客-https://www.hinwi.com/12484.html
7.表中的数据：更新为主的业务 还是 查询为主的业务
8.打算采用什么数据库物理服务器，以及数据库服务器架构？
9.并发如何？
10.存储引擎选择InnoDB还是MyISAM？
大致明白以上10个问题，至于如何设计此类的大表，应该什么都清楚了！
至于优化若是指创建好的表，不能变动表结构的话，那建议InnoDB引擎，多利用点内存，减轻磁盘IO负载，因为IO往往是数据库服务器的瓶颈
另外对优化索引结构去解决性能问题的话，建议优先考虑修改类SQL语句，使他们更快些，不得已只靠索引组织结构的方式，当然此话前提是，
索引已经创建的非常好，若是读为主，可以考虑打开query_cache，
以及调整一些参数值：sort_buffer_size,read_buffer_size,read_rnd_buffer_size,join_buffer_size
其他人建议：
1. 索引, 避免扫描,基于主键的查找,上亿数据也是很快的;
2. 反范式化设计,以空间换时间,避免join,有些join操作可以在用代码实现,没必要用数据库来实现;
评论