支付业务很大程度上依赖于数据库做支持，正确的设置数据库参数以及正确的使用数据库对非常重要，我这把自己之前的一些心得贴出来，抛砖引玉，大家可以把自己的一些心得分享出来供大家参考学习。
一.数据库配置
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中的所有数据库更新记录，上次更新时间都是一致的
