mysql运维1
中台项目中遇到的问题：
1.数据库大：
2.单表大：
3,月增长数据量大
----------------------------------------------------------------------------
一、引入PARTITION表：
1.1如果物理分表，会增大处于快速迭代敏捷开发的中台组工作量和工作难度，因此采用
MYSQL自身分区技术,将对应用侵袭影响降到最低
itf_imp_lines（接口）:按头表ID hash分区
PARTITION BY HASH(HEADER_ID)
PARTITIONS 32;
ae_tfr_dtl_accounts （账务明细表）：每个月一个分区
PARTITION BY RANGE ( to_days( ACCOUNTING_DATE ))(
PARTITION p0 VALUES LESS THAN (TO_DAYS('2018-03-01')),
itf_ar_interface（还款计划表）：每4个月一个分区
PARTITION BY RANGE (I_INCOME_PERIOD)(
PARTITION p0 VALUES LESS THAN (201701),
PARTITION p1 VALUES LESS THAN (201705),
contract_bal（合同余额表）:
ITF_COMMISSION(佣金目标表):
PARTITION BY RANGE ( to_days( ACCOUNTING_DATE )
1.2分区后遇到的问题-----------------------------------------------------------------
ERROR 1503 (HY000): A PRIMARY KEY must include all columns in the table's
partitioning function
分区键必须被添加到PRIMARY KEY定义中！！！
- 分区键数据不可为NULL，因此需要考虑对分区键NULL值刷数
- 死锁！
LATEST DETECTED DEADLOCK
*** (1) TRANSACTION:update h_ae_tfr_dtl_accounts
set TFR_SUM_ACCOUNT_ID =
1766752,summary_flag='Y' where
TFR_DTL_ACCOUNT_ID in (90154363, 90154356,
90158344, 90158337, 90154461, 90150361, ...
*** (2) TRANSACTION:update h_ae_tfr_dtl_accounts
set TFR_SUM_ACCOUNT_ID =
1766743,summary_flag='Y' where
TFR_DTL_ACCOUNT_ID in (90150239, 90142046,
90154332, 90146139, 90137946, 90150232, ...
应对：
1，MYSQL升级（5.7.12-5.7.19）：见效最快
2，应用修改：原UPDATE xxx where PK = XXX
修改为UPDATE xxx where PK = XXX and ‘分区键’ = YYYY：最彻底
二、分库后遇到的问题-----------------------------------------------------------------
2.1 将业务库按一定规则拆分为业务库(h)和归档库(h_archive)，部署在同一数据库实例上；
衍生问题：部分业务逻辑需要业务库关联归档库一起查询，SQL复杂且难以优化
2.2 应对：中台月增数据很大部分来自账务明细表，经项目组小伙伴努力，优化对应明细账未发生则不写入核算中台，将月增数据减少近50%
影响：
1，提高了OTTER同步核算中台数据到EBS的效率；
2，减少了主从同步延时
-------------------------------------------------------
三、性能问题：----------------------------------------------------------
3.1 现象：创建账务期间，MYSQL主从库延迟很大
应对：
1，修改应用，尽量将大事务修改为适中的小事务；(理论最优方案）
2,修改binlog_format:ROW->MIX(效果一般)
3，开启MYSQL并行复制(效果一般)
4，MYSQL升级：5.7.19->5.7.27（综合最佳解决方案）
3.2 现象：多个并发导入任务时，数据加载速度慢
应对：
修改MYSQL默认隔离级别
RR(READ REPEATABLE）-> RC(READ COMMIT)
四、实战参数-----------------------------------------------
innodb_buffer_pool_size:60%-80%物理
innodb_log_file_size： 4G(512MB*3)
max_connections:2000
innodb_file_per_table:ON
innodb_flush_log_at_trx_commit:
1:全ACID支持：每次commit时会将redo buffer写入到redo file，然后刷新到磁盘中
0： COMMIT时不写，每隔一秒将redo buffer写入到redo file，然后刷新到磁盘中（适用于replica)
2： COMMIT时redo buffer写入到redo file ，每隔一秒将刷新到磁盘中
innodb_flush_method:推荐O_DIRECT
fsync: 刷新数据文件和REDO日志时，使用fsync()系统调用；
O_DSYNC: InnoDB 使用O_SYNC 来打开和刷新REDO日志文件；使用fsync()来刷新数据文件
O_DIRECT: InnoDB使用O_DIRECT 来打开数据文件，使用fsync()来刷新数据和REDO日志文件
innodb_log_buffer_size:8M(如果GLOBAL STATUS的innodb_log_waits>0,则增加）
query_cache_size：建议为0
log_bin： ON
skip_name_resolve： ON
