杨尚刚，美图公司数据库高级DBA，负责美图后端数据存储平台建设和架构设计。前新浪高级数据库工程师，负责新浪微博核心数据库架构改造优化，以及数据库相关的服务器存储选型设计。
前言MySQL数据库大家应该都很熟悉，而且随着前几年的阿里的去IOE，MySQL逐渐引起更多人的重视。
MySQL历史年，MontyWidnius写了最初的版本，96年发布1.0
-年，MySQLAB成立，引入BDB
年月，集成MyISAM和rplication
年，HikkiTuuri向MySQL建议集成InnoDB
发布.0，提供了视图、存储过程等功能
8年，MySQLAB被Sun收购，09年推出.1
9年月，Oracl收购Sun，年12月推出.
年2月推出.6GA，.7开发中
MySQL的优点使用简单
开源免费
扩展性“好”，在一定阶段扩展性好
社区活跃
性能可以满足互联网存储和性能需求，离不开硬件支持
上面这几个因素也是大多数公司选择考虑MySQL的原因。不过MySQL本身存在的问题和限制也很多，有些问题点也经常被其他数据库吐槽或鄙视.
MySQL存在的问题优化器对复杂SQL支持不好
对SQL标准支持不好
大规模集群方案不成熟，主要指中间件
ID生成器，全局自增ID
异步逻辑复制，数据安全性问题
OnlinDDL
HA方案不完善
备份和恢复方案还是比较复杂，需要依赖外部组件
展现给用户信息过少，排查问题困难
众多分支，让人难以选择
看到了刚才讲的MySQL的优势和劣势，可以看到MySQL面临的问题还是远大于它的优势的,很多问题也是我们实际需要在运维中优化解决的，这也是MySQLDBA的一方面价值所在。并且MySQL的不断发展也离不开社区支持，比如Googl最早提交的半同步patch，后来也合并到官方主线。FacbookTwittr等也都开源了内部使用MySQL分支版本，包含了他们内部使用的patch和特性。
数据库开发规范数据库开发规范定义：开发规范是针对内部开发的一系列建议或规则,由DBA制定(如果有DBA的话)。
开发规范本身也包含几部分：基本命名和约束规范，字段设计规范，索引规范，使用规范。
规范存在意义保证线上数据库schma规范
减少出问题概率
方便自动化管理
规范需要长期坚持，对开发和DBA是一个双赢的事情
想想没有开发规范，有的开发写出各种全表扫描的SQL语句或者各种奇葩SQL语句，我们之前就看过开发写的SQL可以打印出好几页纸。这种造成业务本身不稳定，也会让DBA天天忙于各种救火。
基本命名和约束规范表字符集选择UTF8，如果需要存储moj表情，需要使用UTF8mb(MySQL..以后支持)
存储引擎使用InnoDB
变长字符串尽量使用varcharvarbinary
不在数据库中存储图片、文件等
单表数据量控制在1亿以下
库名、表名、字段名不使用保留字
库名、表名、字段名、索引名使用小写字母，以下划线分割，需要见名知意
库表名不要设计过长，尽可能用最少的字符表达出表的用途
字段规范所有字段均定义为NOTNULL，除非你真的想存Null
字段类型在满足需求条件下越小越好，使用UNSIGNED存储非负整数，实际使用时候存储负数场景不多
使用TIMESTAMP存储时间
使用varchar存储变长字符串，当然要注意varchar(M)里的M指的是字符数不是字节数；使用UNSIGNEDINT存储IPv地址而不是CHAR(1)，这种方式只能存储IPv，存储不了IPv6
使用DECIMAL存储精确浮点数，用float有的时候会有问题
少用blobtxt
关于为什么定义不使用Null的原因
浪费存储空间，因为InnoDB需要有额外一个字节存储
表内默认值Null过多会影响优化器选择执行计划
关于使用datatim和timstamp，现在在.6.之后又有了变化，使用二者存储在存储空间上大差距越来越小，并且本身datatim存储范围就比timstamp大很多，timstamp只能存储到年
索引规范单个索引字段数不超过，单表索引数量不超过，索引设计遵循B+Tr索引最左前缀匹配原则
选择区分度高的列作为索引
建立的索引能覆盖80%主要的查询，不求全，解决问题的主要矛盾
DML和ordrby和groupby字段要建立合适的索引
避免索引的隐式转换
避免冗余索引
关于索引规范，一定要记住索引这个东西是一把双刃剑，在加速读的同时也引入了很多额外的写入和锁，降低写入能力，这也是为什么要控制索引数原因。之前看到过不少人给表里每个字段都建了索引，其实对查询可能起不到什么作用。
冗余索引例子
idx_abc(a,b,c)
idx_a(a)冗余
idx_ab(a,b)冗余
隐式转换例子
字段:rmarkvarchar(0)NOTNull
MySQLSELECTid,gift_codFROMgiftWHEREdal_id=60ANDrmark=;1rowinst(0.1sc)
MySQLSELECTid,gift_codFROMpool_giftWHEREdal_id=60ANDrmark=‘’;1rowinst(0.00sc)
字段定义为varchar，但传入的值是个int，就会导致全表扫描，要求程序端要做好类型检查
SQL类规范尽量不使用存储过程、触发器、函数等
避免使用大表的JOIN，MySQL优化器对join优化策略过于简单
避免在数据库中进行数学运算和其他大量计算任务
SQL合并，主要是指的DML时候多个valu合并，减少和数据库交互
合理的分页，尤其大分页
UPDATE、DELETE语句不使用LIMIT，容易造成主从不一致
数据库运维规范运维规范主要内容SQL审核，DDL审核和操作时间，尤其是OnlinDDL
高危操作检查，Drop前做好数据备份
权限控制和审计
日志分析，主要是指的MySQL慢日志和错误日志
高可用方案
数据备份方案
版本选择MySQL社区版，用户群体最大
MySQL企业版，收费
PrconaSrvr版，新特性多
MariaDB版，国内用户不多
建议选择优先级为：MySQL社区版PrconaSrvrMariaDBMySQL企业版
不过现在如果大家使用RDS服务，基本还以社区版为主
OnlinDDL问题
原生MySQL执行DDL时需要锁表，且锁表期间业务是无法写入数据的，对服务影响很大，MySQL对这方面的支持是比较差的。大表做DDL对DBA来说是很痛苦的，相信很多人经历过。如何做到OnlinDDL呢，是不是就无解了呢？当然不是！
上面表格里提到的FacbookOSC和.6OSC也是目前两种比较靠谱的方案
MySQL.6的OSC方案还是解决不了DDL的时候到从库延时的问题，所以现在建议使用FacbookOSC这种思路更优雅
下图是FacbookOSC的思路
后来Prcona公司根据FacbookOSC思路，用prl重写了一版，就是我们现在用得很多的pt-onlin-schma-chang，软件本身非常成熟，支持目前主流版本。
使用pt-onlin-schma-chang的优点有：
无阻塞写入
完善的条件检测和延时负载策略控制
值得一提的是，腾讯互娱的DBA在内部分支上也实现了OnlinDDL，之前测试过确实不错，速度快，原理是通过修改InnoDB存储格式来实现。
使用pt-onlin-schma-chang的限制有：
改表时间会比较长(相比直接altrtabl改表)
修改的表需要有唯一键或主键
在同一端口上的并发修改不能太多
可用性关于可用性，我们今天分享一种无缝切主库方案，可以用于日常切换，使用思路也比较简单
在正常条件下如何无缝去做主库切换，核心思路是让新主库和从库停在相同位置，主要依赖slavstartuntil语句，结合双主结构，考虑自增问题。
MySQL集群方案：
集群方案主要是如何组织MySQL实例的方案
主流方案核心依然采用的是MySQL原生的复制方案
原生主从同步肯定存在着性能和安全性问题
MySQL半同步复制：
现在也有一些理论上可用性更高的其它方案
PrconaXtraDBClustr(没有足够的把控力度，不建议上)
MySQLClustr(有官方支持，不过实际用的不多)
红框内是目前大家使用比较多的部署结构和方案。当然异常层面的HA也有很多第三方工具支持，比如MHA、MMM等，推荐使用MHA
sharding拆分问题
Shardingisvry