mysql，sqlserver数据库单表数据过大的处理方式

常常混迹于技术社区，频繁看到这个题目，今天干脆在本身博客重复一遍解决办法：

针对mysql，sqlserver等关系型数据库单表数据过大的处理方式

若是不是阿里云的分布式数据库 DRDS 那种多机器集群方案的话： 先考虑表分区 ；而后考虑分表 ；而后考虑分库。

这个题目是我所经历过的，我作的是GPS应用，早期版本就是选用的关系型数据库Sql Server。当时我选取的方案就是第一种：表分区。 表分区的优点是，若是表结构合理，能够不涉及到程序修改。也就是说，对程序来说依然是单表读写的效果！

全部轨迹数据存入到一个巨大的表里。有多大呢？

• 最大存储量超过10亿行。具体数值应该是12亿多点，因为系统设计为只存储30天轨迹，因此线上期间最大存储只到这个数，再后来采用云架构，上云替换成非关系性数据库，得到了更高的写入性能和存储压缩能力。  
• 每日写入量就超过1500万行。上下班交通高峰时候每秒写入量平均超过500行。也就是500iops，距离系统设计的压测指标3000还有一大截

这张大型单表设计要点：（一个汇集索引用于写入，一个联合索引用于查询，没有主键，使用表分区）

明确主键用途：

真的须要查询单行数据时候才须要主键！

我采用无主键设计，用于避免写入时候浪费维护插入数据的性能。最先使用汇集的相似自增的id主键，压测写入超过5亿行的时候，写入性能缩减一半

准确适用汇集：

写入的数据在硬盘物理顺序上是追加，而不是插入！

我把时间戳字段设置为汇集索引，用于汇集写入目的设计。保证硬盘上的物理写入顺序，不浪费性能用于插入数据

职责足够单一： 

用于精准索引！

使用时间+设备联合索引，保证这张表只有一个查询用途。保证系统只有一种查询目的：按照设备号，查询一个时间段的数据。

精确的表分区：

要求查询时候限定最大量或者最大取值范围！

按天进行表分区，实现大数据量下的高效查询。这里是本文重点，按照汇集索引进行，可让目标数据局限在更小的范围进行，虽然单表数据上亿，可是查询基本上只在某一天的的几千万里进行索引查询

每张表会有各自的特色，不可生搬硬套，总结下我这张表的特色：

只增，不删，不改！

关于不删除中：天天使用做业删除超过30天的那个分区数据除外，由于要清空旧的表分区，腾出新的表分区！

只有一个业务查询：只按照设备编码查询某个时间段

只有一个运维删除：删除旧的分区数据

这张表，是我技术生涯中进步的一个大阶梯，让我我体会到了系统架构的意义。

虽然个人这张举行表看似只有4个关键点，可是这四个很是精准的关键点设计，耗费了我一个月之久！正是这么足够精准的表结构设计，才撑起了后来压测并发量超过3000的并发写入量！压测的指标跟数据库所在的硬盘有直接关系，当时选取的硬盘是4块10000转的SAS盘作了Raid10的环境

关于后来为何没有更高的实际应用数值，是由于系统后来改版为云架构，使用了阿里云，更改成写入性能更高的非关系型数据库MongoDB存储轨迹数据。因此虽然距离压测指标还差很远，可是也没有实际跑到这个数据！单机应用再怎么改造，每次升级都是一件麻烦事，因此应当尽量将瓶颈点提升，甚至消除，云架构的意义就在于弹性扩展，虽然我在数据库方面尚未这方面的成功案例可分享，可是这种架构的意义很明白：未来面对更大的压力，只须要增长服务器数量！    

最后提一句， 不少人以为SSD就足够高的性能了，可是对于云服务器，ssd的性能才跟传统物理机的iops相持平，这是因为虚拟化层面的损失致使的！

原文地址： https://www.opengps.cn/Blog/View.aspx?id=284 文章的更新编辑依此连接为准。欢迎关注源站原创文章！