mysql 航行日志(二): 大表的作死操作影响

大表影响
风险：
相对而言 innerdb并没有明确定义大表规则，一下为个人见解
1，记录行数巨大，单表超过千万行的逻辑表
2，表数据文件巨大，表数据文件超过10G的非日志表
3，相对于日志表而言，五千万行左右，小于50G，视区分度而定
4，日志表意味着出现慢查询的出现，区分度低，堵塞磁盘IO，降低磁盘效率，进阶形成慢查询

 大表对DDL操作的影响
    注1：(建立索引)(修改结构)等都是单线程运行
    1，建立索引需要时间长
        风险：
            MySQL版本 < 5.5 建立索引会产生锁表反应
            MySQL版本 > 5.5 虽然不会锁表但会引起主从延迟
    2，修改表结构需要长时间锁表
        风险：
            会造成长时间的主从延迟  (看注1)
            影响正常数据操作 ( 锁表，堵塞，连接数猛增 )          
            修改表结构时，请不要使用DDL操作

    解决方式： 
             分库分表，拆分大表成小表
    难点：
            分表主键选择（订单号什么的，区分识别度高）
            分表后跨分区数据查询和统计
     建议：
            技术不好请不要作死（会消耗大量人力物力，后期需求变更，更惨）

    解决方式： 
             大表历史数据归档（减少对前后端业务的影响）
    难点：
            归档时间点选择（很少操作的时间点）
            如何进行归档操作
     建议：
            这个是属于较好的方式，主要注意主从延迟和归档时的数据操作