本文介绍了如何处理mysql和sqlserver等数据库中单表数据过大的问题，提出了先考虑表分区，再考虑分表，最后考虑分库的策略。以GPS应用为例，详细阐述了采用表分区的设计思路，包括无主键设计、时间戳作为聚集索引、联合索引和按天分区的方法，以实现高效查询和写入。通过这些精准设计，支撑了高并发写入的需求，但在面临更大压力时，建议转向云架构和非关系型数据库如MongoDB。
经常混迹于技术社区，频繁看到这个题目，今天干脆在自己博客重复一遍解决办法：
针对mysql，sqlserver等关系型数据库单表数据过大的处理方式
如果不是阿里云的分布式数据库 DRDS 那种多机器集群方案的话： 先考虑表分区 ；然后考虑分表 ；然后考虑分库。
这个题目是我所经历过的，我做的是GPS应用，早期版本就是选用的关系型数据库Sql Server。当时我选取的方案就是第一种：表分区。 表分区的优势是，如果表结构合理，可以不涉及到程序修改。也就是说，对程序来讲依然是单表读写的效果！
所有轨迹数据存入到一个巨大的表里。有多大呢？
-
最大存储量超过10亿行。具体数值应该是12亿多点，由于系统设计为只存储30天轨迹，所以线上期间最大存储只到这个数，再后来采用云架构，上云替换成非关系性数据库，获得了更高的写入性能和存储压缩能力。
-
每日写入量就超过1500万行。上下班交通高峰时候每秒写入量平均超过500行。也就是500iops，距离系统设计的压测指标3000还有一大截
这张大型单表设计要点：（一个聚集索引用于写入，一个联合索
最低0.47元/天 解锁文章
扫一扫
1621
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
