转| 阿里内部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中的所有数据库更新记录，上次更新时间都是一致的