mysql使用规范与建议(一)

10 Nov 2014

使用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.在数据变大之前做好拆分或归档准备