使用mysql过程中遵循着一些规范与建议，但是天知道随着mysql版本的更新与具体业务的不同，这些规范与建议还是否试用。 遵循规范与建议目的是获取足够的性能来支撑业务逻辑，如果实践过程中一味的追求符合规范，那就是本末倒置了。
数据库设计解耦
数据库层级的设计不限于在mysql了。
业务层级解耦
使用之前电商系统建构的例子，各种主要业务的数据库独立存在（实例级），业务交互走接口。
活动数据与历史数据解耦
看具体业务将活动数据与历史数据分表或分库进行存储。一些数据是会随时间积累的，订单呀，各种操作记录呀等等，都放在一张表里面的话， 没几年数据库就跑不动了...
mysql设计类规范
不在数据库中存储图片、文件，不使用大文本类型
表示没有在mysql或是其他数据库中存储过这样的数据，不了解性能会差到怎样的一个地步...
通常图片与一些xml文件（如sitemap）以文件的形式直接存储在系统内或cdn上。
不使用外键，由程序保证数据一致性
一直在强调这一点，哪里都不让用外键，当初把这么个东西设计出来是干咩的呀...
回一下所学，外键是加在数据表某一列上的限制条件（限制条件，比如某一列表示性别，只能从‘男’或‘女’中取值），所以被加上外链的 列的取值范围是由另一个表（或自身）的某一列的值决定的，超出这个范围则会认定记录不合法。
还记得有一个叫作级联删除的东西，可以把被外键连接的记录一起删除掉。
不使用外键，即在数据库层级少了一层业务逻辑上的约束（比如订单明细记录，必须有一张订单主表上的记录与其做外键）。通常这些约束不是必要的 （比如把订单主表的一条记录删除，但是订单明细没有被删，写统计sql的时候可能出现误差，不是很重要），另数据库资源通常是稀缺的，整体系统的 瓶颈所在，所以尽量使其管理少的必要的事情，外链就不要加了，由程序来搞定。
（曾想唯一索引这个事情也由程序来做，放松数据库，但是涉及到主从同步延时（可能还有脏读情况），由程序来做是一件困难的事情）
禁止使用存储过程、触发器
实际项目中使用到存储过程、触发器的例子：
1.业务单据采号，流水号+业务前缀
2.使用存储过程实现委托加工整体流程...
3.使用存储过程封装一套业务逻辑操作多个表
4.使用触发器（插入或更新）记录keywords相关操作日志
1.利用了数据库自带函数采号，功能单一，这样实现更便捷，个人觉得这是挺好的一种方式。（数据库是由dba管理的，存储过程代码不能由程序员 直接掌控，而且现在的程序员会写存储过程的不多...维护起来挺费事的，有的时候就是要调用主库的这个存储过程而增加一个连接串,也挺讨厌的） 也可以考虑使用程序封装一套采号逻辑，谁用谁调用也挺不错的。（ruby gem 的易用性体现了）
2.业务逻辑复杂，极难维护
3.同2
4.想不记日志都不行呀，批量更新了10W keywords数据，触发器记日志损耗了绝大部分性能，还容易产生锁。
总结：有存储过程和触发器存在的数据库，业务代码与数据库耦合关系变紧，开发要考虑更多的情况来保证性能，并且难以维护，根据实际情况慎用（有的时候可以 省很多很多代码 哈哈哈）。
每张表数据量控制在2000W以下 ，如预计会超出，需提前做好拆分或者归档迁移计划
不清楚2000W这个数是怎么出来的，试验出这个数字的mysql版本 数据库引擎 试验所用表的具体结构都没有明确说明。目前已经存在个别表数据超出2000w， 性能并没有明显下降，但是有两点可以确定：
1.数据表不能过大，否则会影响性能 2.在数据变大之前做好拆分或归档准备