Mysql规范50条

支付业务很大程度上依赖于数据库做支持，正确的设置数据库参数以及正确的使用数据库对非常重要，我这把

自己之前的一些心得贴出来，抛砖引玉，大家可以把自己的一些心得分享出来供大家参考学习。

一.数据库配置
1.
innodb_flush_log_at_trx_commit,这个对支付业务来说是关键性的设置之一，可选的参数值有0,1,2, 支付需要设置成1.

2. 对交易以及记账部分来说，必须是innode引擎,以支持事务

3. 事务隔离级别，权衡安全性和效率，使用可重复读

4. innodb_lock_wait_timeout,这个是锁超时时间，不建议太大，怕引起雪崩

二.业务设计
1. 不用物理删除，即尽量避免用delete语句，drop命令等;通过软删除处理，即通过额外的字段标

2. 明记录的删除状态;虽然对写代码来讲有些麻烦，但实践证明是非常值得的

3. 在系统设计之初就要定好编码规范，对存入的数据做相应转换并做好escape处理

4. 除列表查询外，尽量用主键操作;核心交易系统中尽量避免非主键操作

5. 避免schema中1对多设计，概念简单，编码很难

6. 就mysql来说，尽量使用其最简单的功能，不用其高级功能如触发器，连表等

7. 就mysql来说，尽量不让其做计算功能，而是让业务层来实现计算逻辑

8. 当要锁多条记录时， 要考虑死锁的可能以及预防的措施

9. 按业务垂直划分原则，尽量把不同的业务方不同的库中

10. 坚持小事务，一个大事务与将其拆分成的十个小事务相比，小事务对数据库压力更小;另外，事务

中做尽可能少的事情，神马参数校验之类的事情能拉出去就拉出去

11. 数据库连接长时间不用超时断开是常见的，应用中需要考虑

12. 对超大型系统来说，分布式事务是有价值的;但在大多下情况下，单机事务能很好的满足需要

13. 主从延迟总是会有的，有时候会很大，设计中要考虑

14. 读写账号分开，读账号select权限即可，写账号update，insert即可

15. where条件key='value'的模式中，加上单引号总是对的，不加在某些情况下有很多令人意外的副

作用

16. 尽量使用简单的数据类型，char系列，int系列以及date系列即可

17. 事务的使用上，在线交易使用悲观锁

18. 事务框架的选择上，使用控制力度比较大的，直接TransactionManager，不推荐使用声明式事务

19. 采用InnoDB引擎，UTF8编码

20. 有状态字段的记录，状态的取值不宜太多， 6 ~ 7个应该是上限了， 最好不要超过 4个

21. 每个表都应该有自己的主键，且尽量让表内主键保持递增

22. 不使用自增主键

23. 在线查询的字段一定要建立覆盖索引

24. 分页查找一定不能直接limit m，n，一定要做优化

三. 应用规范
1. 当进行账户余额变化操作时，总是校验账户是否被冻

2. 对单据如Trade，Charge进行处理，并发总是要考虑的，需要锁记录后进行校验;从数据库查询的

时候，请先起动事务，并用select...for update;防止并发带来的问题;从性能上将，锁交易单本身不

会成为性能瓶颈

3. 更新账户余额之前必须加锁，即起事务+select...for update; 更新余额的语句建议是update table

set 余额=余额+/-发生额， 自然在代码逻辑中做各种边界值校验，包括不溢出，不小于0等

4.金额都统一单位，以分为单位合适;数据类型为有符号64位整形数合适

5. 对金额计算时，对溢出的预防总是需要的

6.使用select时，慎用*,尽量明确的枚举出字段名

7.与外部交互的地方，记录下外部发生时间

8. db命名采用"cashpay"前缀

9. 表命名采用"t_"前缀

10. 字段命名采用"F_"前缀

11. 每个表都会有一个字段记录上次更新时间

12. 在一个session中的所有数据库更新记录，上次更新时间都是一致的