主从复制延时缓解
1.从库是SSD硬盘。（主库是非SSD硬盘）
2.尽量避免主库大量的写入，异步写。
3.主库和从库直接使用专用网络，高速互联。
4.对于数据一致性要求严格的，不要查从库。
5.减少从库压力，例如使用多个从库。
------------------------------------>其实每步都会延伸出其他问题。主从延时是不可能解决的，只能缓解。
经验：
1.生产应用mysql用户。不允许delete。 insert update select
2.有条件的情况下，做一个延迟1小时的从库。
3.所有DML必须备份 # dml_backup.sh table_name
4.创建一个和你执行alter表相同的表结构 tmp.
5.执行tmp表结构修改，从原表copy数据到修改后的表。
6.在原表上创建触发器，将copy过程中产生的数据，更新到新表。
7.copy完成，rename.
8.大数据删除或者转存。
9.mysqldump的时候，要去掉 drop table 语句。
10.删除的时候，按id，分批删除，最好写个脚本，放screen里面。
数据库操作必须有两个脚本
1.修改脚本
2.数据回滚脚本
做完主从复制，第一步就要在从库上做read only，然后再对外！为什么？？？有人说反正从库我们肯定不写，那是你以为你不写，但是tmd有天开发写了，主从故障了这个锅谁背。
mysql> flush table with read lock;
如果你知道是开发写的从库还好，那你要是根本就不知道是开发写的从库呢，这个锅就是你的！
就算这锅是开发的，领导也会问你，从库为什么能写呢？？？
运维背黑锅就是自己能力不行，不服就去PK.
硬件的优化：
1.采用64位cpu，cpu至少4颗，L2缓存越大越好。
2.内存要大，32-64G运行1-2个实例，96-128G运行3-4个实例。
3.机械盘选用sas盘，转速15000以上，用可能的话使用ssd.
4.raid卡使用raid10.
5.网卡多块，千兆以上。
6.数据库不要使用虚拟化，slave硬件要好于master.
操作系统优化
1.操作系统选择x86_64位，尽量采用xfs文件系统。
2.优化磁盘存储参数。
3.优化内核参数。
4.优化网络等。
mysql构架优化
1.根据内存大小，配置服务器跑多实例。
2.主从复制采用mixed模式，尽量不要跨机房同步，若要跨机房，尽量采用远程写，本地读。
3.定期检查、修复主从复制的数据差异。
4.业务拆分，搜索功能不使用MySQL数据库执行；某些高并发，安全性一般的业务使用nosql，如：memcache、 redis等。
5.数据库前端加cache，如memcache，用于用户登录，商品查询。
6.动态数据静态化，整个文件静态化，页面片段静态化。
7.数据库集群读写分离，一主多从，通过dbproxy进行集群读写分离。
8.单表超过800万，拆库拆表，如人工将（登录、商品、订单）拆表拆库。
9.选择从库备份，并且对数据库进行分表分库备份。
MySQL数据库层面优化
1.优化my.cnf参数。
2.优化库表设计，包括字符集、字符串长度、创建短索引、多用复合索引。
3.SQL语句优化，减少慢语句数量。
数据库管理流程、制度优化
1.人的流程：开发—>核心运维/DBA.
2.测试流程：内网 IDC测试线上执行。
3.客户端管理，PHPMYADMIN.
MySQL数据库安全优化
1.数据库禁止设置外网。
2.数据库文件权限优化。
3.授权用户权限限制，尽量专库专用户。
4.限制开发对生产库的操作权限。
5.防止SQL语句注入。
