mysql 编程，在高并发环境下的使用特点

 

 

 

　　如下是在某次做并发编程时，对mysql做的一些相关操作。

 

业务层优化

 

1、事务型操作入口

　　

　　根据每次事务发生时需要执行的事务数量，分为单一事务处理和多事务处理。

 

单一事务入口

 

失败处理：

　　失败统一回滚

 

多事务入口

 

多事务处理优势：

　　可以建立事务回滚的存储点。

　　

失败处理：

　　针对失败的事务做回滚。如叶子事务失败，则回滚叶子事务；如果子事务失败，则令子事务，连带其叶子事务一起回滚。

 

 

 

2、单一数据入口

 

数据特点：

1、只有一条数据

失败记录日志，无回滚

 

 

2、多条不同操作的数据

 

失败的那一条数据记录日志，没有出现错误的继续执行，无回滚

 

 

 

3、批量数据入口

 　　

一条语句的批量操作

1、批量插入

 

失败记录日志，无回滚

 

2、批量更新

 

失败记录日志，无回滚

 

多条语句的批量操作

 

记录失败的日志，无回滚

 

3、

数据是否回滚

不用回滚

 

批量操作时，应该注意，同一条数据在一个批量里出现两次，应该如何处理。有的数据出现两次是无所谓，因为本身业务性质是直接；但是有的业务对某些数据要求是唯一性，这时如果出现了两条一样的记录（这里的一样，指索引时一样，但是业务数据不一样），就需要慎重的考虑了。

 

 

4、在server端，尽可能少的执行删除操作。

　　通常不推荐在server端做数据删除操作，如果遇到业务非执行不可，做一个状态位标记为删除即可。原因是因为mysql在底层实现了自己的IO操作，mysql B+树结构能够让数据按照索引顺序紧密排列存储在一起，当执行删除操作时会打破这种连续紧密的结构，造成了存储空间的无序性，这样在后续的存储和查询时都会产生不必要的IO跳转（如：磁盘换道，跳换扇区）。

　　

5、在server端，使用数据库时，避免整个项目使用一个连接。

　　mysql的连接存在使用时间上限，当长时间不使用时会断开，session也有一个最大的连接上限时间，避免一个项目长期使用一个连接。一般这种情况会有以下报错：

 

　　　　MySQL server has gone away (BrokenPipeError(32, 'Broken pipe'

 

 

设计层优化

 

1、取消外键关联，在业务层保证数据的完整性

 

2、统一类型的数据，如果记录在不同表中，保证数据条数一样多。

　　如客户端信息表，新客户端产品信息表。一个客户端对应一个客户端的产品信息，这样两张表数据条数一样，不要将客户端分组信息丢在客户端表里，一是如果没有外键关键，无法知道到底是否一致了，二是，在数据量很大，做组查询时扫描行数太多，性能太浪费。

 

3、减少表的JOIN个数

 

4、表索引不要太多，否则会影响高并发，尤其是需要大量写入的表和架构

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

一些特殊操作

 

1、insert on duplacitate  update

 

2\

 

 

单实例实现的缺陷问题

 

问题引起原因：

       1、为了避免创建多个数据库连接池，在使用数据库接口时，多会使用单实例的方式来编程，这时单实例编程会遇到一个很有意思的问题，就是数据库意外关闭后重启，数据库连接池失效，需要重新生成一个连接池，而单实例的本质是使用一个连接池，于是问题就来了。

　　2、数据库的连接存在一个超时时间，如果长时间没有数据上报，数据库的连接会被数据库断开。