版权声明：本文为博主原创文章，未经博主允许不得转载。
背景
项目数据表要进行迁库，由于原项目的数据表是逻辑删除，没有进行物理删除，从项目启动开始的2015年1月，V1数据表的数据量已达到了6300W，V2数据表的数据量为1200W。
迁库前业务方需要对我们对V1V2数据表进行清理，只保留目前参与计算的城市的数据。
配了一个Hive2MySQL任务进行操作，清理SQL使用了“delete from table”语句。
V2数据表（1200W）的清理任务耗时6分钟24秒执行成功。
V1数据表由于数据量过大（6300W），耗时27分钟8秒，任务失败，报错连接超时。而使用的delete语句为DML（data maintain Language)，这个操作会被放到 rollback segment中，事务提交后才生效。由于任务失败，事务没有提交，删除操作并没有生效。
executor throws an exception when execute runner Communications link failure The last packet successfully received from the server was 1,593,719 milliseconds ago. The last packet sent successfully to the server was 1,593,719 milliseconds ago.
引发的思考
① 若数据量较大，且数据有备份，在不改变库表设计的情况下，Hive2MySQL任务的清理SQL可尝试使用“TRUNCATE”
TRUNCATE 执行权限需要找DBA配置，数据库管理平台不能进行该权限的配置。
说明：TRUNCATE TABLE 在功能上与不带 WHERE 子句的 DELETE 语句相同，但速度比 DELETE 快。
DELETE语句执行删除的过程是每次从表中删除一行，并且同时将该行的删除操作作为事务记录在日志中保存以便进行进行回滚操作。
TRUNCATE TABLE 比 DELETE 速度快，且使用的系统和事务日志资源少；一次性地从表中删除所有的数据并不把单独的删除操作记录记入日志保存，删除行是不能恢复的；并且在删除的过程中不会激活与表有关的删除触发器。使用时需确保数据有备份。
② 合理的库表设计
详细可参阅 MySQL数据库操作规范
出现该问题有部分原因是V1数据表由于数据量过大（6300W）。
DBA推荐的每张表数据量建议控制在5000W以内。
若数据量超出该量级，则可进行合理的库表设计：
- 推荐使⽤HASH进行拆表，表名后缀使用⼗进制数，数字必须从0开始。
- 按⽇期时间分表需符合YYYY[MM][DD][HH]格式，例如2018071601。年份必须用4位数字表示。例如按日散表user_20180709、按月散表user_201807。
- 采用合适的分库分表策略。例如千库十表、⼗库百表等。
采用合适的分库分表策略，有利于业务发展后期快速对数据库进⾏⽔平拆分，同时分库可以有效利用MySQL的多线程并行复制特性。—— 摘自 MySQL数据库操作规范
③ 线上数据表操作需考虑上下游，谨慎合理操作
本次数据表清理，未完全考虑上下游依赖任务。清库操作在MySQL2Hive任务之前，导致同步到数仓的hive表无数据，影响下游依赖的项目无数据。
因此在进行数据表清理这种影响较大的数据表操作时，需提前考虑上下游依赖关系，谨慎合理操作。
④ 线上MySQL操作建议在 数据库管理 平台执行
对于线上MySQL操作，如本次的单次清理任务，建议走数据库管理平台，该平台底层保证了任务的安全。
如执行SQL整个过程可以认为不添加锁（只是在最后阶段瞬间加一个锁，持续时间很短，即便有阻塞会自动触发保护机制），不会对线上读写造成影响。
--------------------------文档信息--------------------------
版权声明：本文为博主原创文章，未经博主允许不得转载
署名(BY) ：dkjkls（dkj卡洛斯）
文章出处：http://blog.csdn.net/dkjkls