MySQL架构设计谈：从开发规范、选型、拆分到减压(一)

本文大纲：MySQL数据库开发规范MySQL高可用架构选型MySQL Sharding拆分利用NoSQL为MySQL减压一、MySQL数据库开发规范

数据库规范到底有多重要？有过初创公司经历的朋友应该都深有体会。规范是数据库运维的一个基石，能有效地减少数据库出问题的概率，保障数据库schema的合理设计并方便后续自动化的管理。

曾经我们花了大半年时间来做数据库规范化的工作，例如制定数据库开发指南、给程序员做培训等，推进的时候也会遇到一些阻力。但规范之后运维质量会有一个质的提升，也增进了DBA的工作效率。

在开发规范方面，我们划分为开发规范和运维规范两部分。

1、开发规范

表设计的规范：字段数量建议不超过20-50个做好数据评估，建议纯INT不超过1500万，含有CHAR的不要超过1000万。字段类型在满足需求条件下越小越好，尽量使用UNSIGNED存储非负整数，因为实际使用时候存储负数的场景不多。将字符转换成数字存储。例如使用UNSIGNED INT存储IPv4 地址而不是用CHAR(15) ，但这种方式只能存储IPv4，存储不了IPv6。另外可以考虑将日期转化为数字，如：from_unixtime()、unix_timestamp()。所有字段均定义为NOT NULL，除非你真的想存储null。

索引设计的规范：

1）所有表必须有显式主键InnoDB表是以主键排序存储的IOT表尽量使用短、自增的列做索引复制结构使用row格式，如果表有主键可以加速复制UNSIGNED INT自增列，也可以考虑BIGINTTINYINT做主键可能导致MySQL Crash类型转换会导致查询效率很低可用uuid_short()代替uuid()，转成BIGINT存储

2）合理地建立索引选择区分度高的列作为索引单个索引字段数不超过5，单表索引数量不超过5，避免冗余索引建立的索引能覆盖80%主要的查询，不求全，解决问题的主要矛盾复合索引排序问题，多用explain去确认

SQL编写规范：

1）避免在数据库中进行大量计算任务大事务拆成多个事务，分批多次操作慎用text、blob大型字段，如要用考虑好拆分方案频繁查询的字典表考虑用Cache抗

2）优化join避免大表与大表之间的join，考虑让小表去驱动大表join最多允许三表join，最好控制成两表控制join后面where选择的行数

3）注重where条件，多用EXPLAIN确认where条件的字段，尽量用区别度高的字段，这样走索引的性能更好出现子查询的SQL，先确认MySQL版本，利用explain确认执行计划进行分页优化;DML时候多个value合并

Schema Review：

1）字符集问题

表字符集选择UTF8 ，如果需要存储emoj表情，就改成UTF8mb4

2）Schema设计原则核心表字段数量尽可能地少，有大字段要考虑拆分适当考虑一些反范式的表设计，增加冗余字段，减少JOIN资金字段考虑统一*100处理成整型，避免使用decimal浮点类型存储日志类型的表可以考虑按创建时间水平切割，定期归档历史数据

3）Schema设计目标快速实现功能为主，保证节省资源平衡业务技术各个方面，做好取舍不要在DB里进行大计算，减少复杂操作

整体来说，这部分规范还是很容易遵守的，实现起来也没有什么难度，就能取得很好的效果。