数据库死锁意见
数据库在多进程操作时候很容易发生死锁，对此需要注意一下几点：
1. 事务级别为repeatable-read时，InnoDB存在Gap-Lock，可能导致insert或者delete操作失败，此时将事务级别降为read-committed
2. 降低每次事务操作的数据量，降低死锁发生的可能性
3. 优化表设计，特别是大表和操作复杂的表。每个表都要有主键。在InnoDB中没有索引的查找，会产生表级所。
4. 发生锁表之后，首先回滚，等待一段时间后再次尝试。
5. 最重要的一点：查看数据库配置的内存是否足够。当内存不足且操作数据库频繁时，就会有部分操作等待延迟（可以查看慢日志，需要配置慢日志），进而增大的死锁发生概率。
查看锁表时，可以查看show engine innodb statusG，观察锁表信息。
内存设置
1. 每台服务器上最优只配置1个MySQL实例。不过从实际操作来看，只要内存资源足够，多实例也没有问题。
2. 在INNODB下，MySQL内存主要看innodb_buffer_pool_size值的大小。
2. 对于冷热均匀的MySQL数据库，可以按照数据库容量：内存 = 1:5配置。具体来说：
如果我们的所有MySQL数据大小为7GB，则每个的MySQL实例内存大小为1GB
3. 每个MySQL表的指纹数不超过2000万条，且不设立分区表。
4. MySQL的buffer_pool会逐渐增大到设置值，所以内存值不宜设置过大，否则占用太多内存空间
时区设置
查看log的时候，发现log上的时间不对，原来MySQL区分了log_timestampe，需要重新设置日志时间，如下：
show global variables like 'log_timestamps';
set global log_timestamps=SYSTEM;
另外，可以设置MySQL所处的时区：
show variables like "%time_zone%"；
set global time_zone = '+8:00'；
select now();
flush privileges;
设置为东八区
慢日志清空
set global slow_query_log=0;
set global slow_query_log_file='/opt/wifidb/logs/mysql/3306/mysqld3306_slow.log';
set global slow_query_log=1;
bin-log清空
# mysql -u root -p
> purge master logs to 'mysql-bin.010’; //清除mysql-bin.010日志
> purge master logs before '2016-02-28 13:00:00'; //清除2016-02-28 13:00:00前的日志
> purge master logs before date_sub(now(), interval 3 day); //清除3天前的bin日志
GTID多线程复制
[mysqld]
gtid_mode=on ---开启
enforce_gtid_consistency=on
log_slave_updates=1 ---从机可以挂在其他从机
binlog_format=row ----行log
skip_slave_start=1 ----从机不开机复制
slave_parallel_type = LOGICAL_CLOCK ---组提交
slave_parallel_workers=16 ---复制进程数
master_info_repository = TABLE
slave_preserve_commit_order = 1
relay_log_info_repository=TABLE
relay_log_recovery=ON
在从机上运行
change master to
master_host='172.16.2.62',
MASTER_PORT=3306,
master_user='wifi',
master_password='HiGeo123',
master_auto_position=1;
GTID中途复制
SET GLOBAL gtid_purged="8133046e-4282-11e6-848e-026ca51d284c:1-4920155";
purge binary logs to 'mysql-bin-3306.000003';