13518219792
最近遇到了一个坑，MySQL数据库服务器硬盘容量告警，而且因为非技术原因，还不能追加硬盘。
创新互联公司是一家集网站建设,湘西土家族企业网站建设,湘西土家族品牌网站建设,网站定制,湘西土家族网站建设报价,网络营销,网络优化,湘西土家族网站推广为一体的创新建站企业，帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿，时刻以成就客户成长自我，坚持不断学习、思考、沉淀、净化自己，让我们为更多的企业打造出实用型网站。
通过监控发现，磁盘IO一直100%。直接影响就是系统处理时间越来越长，接口响应耗时也越来越多。
经过分析，发现mysql业务数据库里有好几张大表，而且这几张大表行数都在5000万以上，文件大小都在100G和150G之间。
因为这些表都是备份表，第一反应就是找DBA直接清理掉这些表。 潜意识里以为drop table 和 truncate table效率很高，都会快速完成，但事实上不是。 但意外的是，在执行drop table时，直接导致数据库挂起了，而且还发生了主从切换。
第一次尝试失败。
第一次失败反应出来的问题是，如果数据文件过大，drop table操作也得慎用。
那我们可以在drop table之前，想办法把数据文件逻辑清空。比如Linux硬连接的方式，具体步骤如下（假如目标表名是test）：
ln test.ibd test.ibd.hdlk
drop table test;
此时，磁盘上真实的数据其实没删除，但数据库里的表，已经删除了。
rm test.ibd.hdlk
到此，数据就能快速清理成功了。
请点击输入图片描述（最多18字）
经常混迹于技术社区，频繁看到这个题目，今天干脆在自己博客重复一遍解决办法：
针对mysql，sqlserver等关系型数据库单表数据过大的处理方式
如果不是阿里云的分布式数据库 DRDS 那种多机器集群方案的话： 先考虑表分区 ；然后考虑分表 ；然后考虑分库。
这个题目是我所经历过的，我做的是GPS应用，早期版本就是选用的关系型数据库Sql Server。当时我选取的方案就是第一种：表分区。 表分区的优势是，如果表结构合理，可以不涉及到程序修改。也就是说，对程序来讲依然是单表读写的效果！
所有轨迹数据存入到一个巨大的表里。有多大呢？
最大存储量超过10亿行。具体数值应该是12亿多点，由于系统设计为只存储30天轨迹，所以线上期间最大存储只到这个数，再后来采用云架构，上云替换成非关系性数据库，获得了更高的写入性能和存储压缩能力。
每日写入量就超过1500万行。上下班交通高峰时候每秒写入量平均超过500行。也就是500iops，距离系统设计的压测指标3000还有一大截
这张大型单表设计要点：（一个聚集索引用于写入，一个联合索引用于查询，没有主键，使用表分区）
明确主键用途：
真的需要查询单行数据时候才需要主键！
我采用无主键设计，用于避免写入时候浪费维护插入数据的性能。最早使用聚集的类似自增的id主键，压测写入超过5亿行的时候，写入性能缩减一半
准确适用聚集：
写入的数据在硬盘物理顺序上是追加，而不是插入！
我把时间戳字段设置为聚集索引，用于聚集写入目的设计。保证硬盘上的物理写入顺序，不浪费性能用于插入数据
职责足够单一：
用于精准索引！
使用时间+设备联合索引，保证这张表只有一个查询用途。保证系统只有一种查询目的：按照设备号，查询一个时间段的数据。
精确的表分区：
要求查询时候限定最大量或者最大取值范围！
按天进行表分区，实现大数据量下的高效查询。这里是本文重点，按照聚集索引进行，可以让目标数据局限在更小的范围进行，虽然单表数据上亿，但是查询基本上只在某一天的的几千万里进行索引查询
每张表会有各自的特点，不可生搬硬套，总结下我这张表的特点：
只增，不删，不改！
关于不删除中：每天使用作业删除超过30天的那个分区数据除外，因为要清空旧的表分区，腾出新的表分区！
只有一个业务查询：只按照设备编码查询某个时间段
只有一个运维删除：删除旧的分区数据
这张表，是我技术生涯中进步的一个大阶梯，让我我体会到了系统架构的意义。
虽然我的这张举行表看似只有4个关键点，但是这四个非常精准的关键点设计，耗费了我一个月之久！正是这么足够精准的表结构设计，才撑起了后来压测并发量超过3000的并发写入量！压测的指标跟数据库所在的硬盘有直接关系，当时选取的硬盘是4块10000转的SAS盘做了Raid10的环境
关于后来为什么没有更高的实际应用数值，是因为系统后来改版为云架构，使用了阿里云，更改为写入性能更高的非关系型数
这么大的表优化是很痛苦的，看你对数据的用途，如果不经常查询、而是频繁的增加，可以考虑定期（每周或者每日）把表中的数据复制到历史表中，清空工作表的数据，这样插入的效率能大大提高，但是查询的时候需要在两个表中进行查询。用于频繁插入数据的工作表要尽量少建索引，用于查询的历史表要多建索引。
优化方案：
主从同步+读写分离：
这个表在有设备条件的情况下，读写分离，这样能减少很多压力，而且数据稳定性也能提高
纵向分表：
根据原则，每个表最多不要超过5个索引，纵向拆分字段，将部分字段拆到一个新表
通常我们按以下原则进行垂直拆分:（先区分这个表中的冷热数据字段）
把不常用的字段单独放在一张表;
把text，blob等大字段拆分出来放在附表中;
经常组合查询的列放在一张表中;
缺点是：很多逻辑需要重写，带来很大的工作量。
利用表分区：
这个是推荐的一个解决方案，不会带来重写逻辑等，可以根据时间来进行表分区，相当于在同一个磁盘上，表的数据存在不同的文件夹内，能够极大的提高查询速度。
横向分表：
1000W条数据不少的，会带来一些运维压力，备份的时候，单表备份所需时间会很长，所以可以根据服务器硬件条件进行水平分表，每个表有多少数据为准。
