MYSQL多线程并发操作同一张表同一个字段的问题有什么办法解决吗?被操作的字段都建立了普通索引。

比如一张表有商品名字、销售序列号、商品售价、进价、销售数等几个字段,

另外销售序列号、商品售价、进价三个字段分别设了普通索引,如果同一个时间点多个线程操作这张表,并且同时修改销售数,就会出现售销数量不正确的问题。

比如A线程在修改销售数时原来销售数是50,卖掉一件就会+1,而同时B\C\D等几个线程也同时购买,那么就会出现几个线程买完销售数都只是51,这个问题有什么办法解决?

innodb引擎的行锁能否解决问题?如果几个线程同时进行操作会不会出错?能不能告诉我实现方法?

在MySQL 8.0 之前, 我们假设一下有一条烂SQL,

mysqlselect * from t1 order by rand() ;

以多个线程在跑,导致CPU被跑满了,其他的请求只能被阻塞进不来。那这种情况怎么办? 


大概有以下几种解决办法:

    设置max_execution_time 来阻止太长的读SQL。那可能存在的问题是会把所有长SQL都给KILL 掉。有些必须要执行很长时间的也会被误杀。

    自己写个脚本检测这类语句,比如order by rand(), 超过一定时间用Kill query thread_id 给杀掉。

    那能不能不要杀掉而让他正常运行,但是又不影响其他的请求呢?

    那mysql 8.0 引入的资源组(resource group,后面简写微RG)可以基本上解决这类问题。

    比如我可以用 RG 来在SQL层面给他限制在特定的一个CPU核上,这样我就不管他,让他继续运行,如果有新的此类语句,让他排队好了。

    为什么说基本呢?目前只能绑定CPU资源,其他的暂时不行。

    那我来演示下如何使用RG。

    创建一个资源组user_ytt. 这里解释下各个参数的含义,

    type = user 表示这是一个用户态线程,也就是前台的请求线程。如果type=system,表示后台线程,用来限制mysql自己的线程,比如Innodb purge thread,innodb read thread等等。

    vcpu 代表cpu的逻辑核数,这里0-1代表前两个核被绑定到这个RG。可以用lscpu,top等列出自己的CPU相关信息。

    thread_priority 设置优先级。user 级优先级设置大于0。

    mysqlmysql> create resource group user_ytt type = user  vcpu = 0-1 thread_priority=19 enable;Query OK, 0 rows affected (0.03 sec)


    RG相关信息可以从 information_schema.resource_groups 系统表里检索。

    mysqlmysql> select * from information_schema.resource_groups;+---------------------+---------------------+------------------------+----------+-----------------+| RESOURCE_GROUP_NAME | RESOURCE_GROUP_TYPE | RESOURCE_GROUP_ENABLED | VCPU_IDS | THREAD_PRIORITY |+---------------------+---------------------+------------------------+----------+-----------------+| USR_default         | USER                |                      1 | 0-3      |               0 || SYS_default         | SYSTEM              |                      1 | 0-3      |               0 || user_ytt            | USER                |                      1 | 0-1      |              19 |+---------------------+---------------------+------------------------+----------+-----------------+3 rows in set (0.00 sec)


    我们来给语句select guid from t1 group by left(guid,8) order by rand() 赋予RG user_ytt。

    mysql> show processlist;+-----+-----------------+-----------+------+---------+-------+------------------------+-----------------------------------------------------------+| Id  | User            | Host      | db   | Command | Time  | State                  | Info                                                      |+-----+-----------------+-----------+------+---------+-------+------------------------+-----------------------------------------------------------+|   4 | event_scheduler | localhost | NULL | Daemon  | 10179 | Waiting on empty queue | NULL                                                      || 240 | root            | localhost | ytt  | Query   |   101 | Creating sort index    | select guid from t1 group by left(guid,8) order by rand() || 245 | root            | localhost | ytt  | Query   |     0 | starting               | show processlist                                          |+-----+-----------------+-----------+------+---------+-------+------------------------+-----------------------------------------------------------+3 rows in set (0.00 sec)


    找到连接240对应的thread_id。

    mysqlmysql> select thread_id from performance_schema.threads where processlist_id = 240;+-----------+| thread_id |+-----------+|       278 |+-----------+1 row in set (0.00 sec)


    给这个线程278赋予RG user_ytt。没报错就算成功了。

    mysqlmysql> set resource group user_ytt for 278;Query OK, 0 rows affected (0.00 sec)


    当然这个是在运维层面来做的,我们也可以在开发层面结合 MYSQL HINT 来单独给这个语句赋予RG。比如:

    mysqlmysql> select /*+ resource_group(user_ytt) */guid from t1 group by left(guid,8) order by rand()....8388602 rows in set (4 min 46.09 sec)


    RG的限制:

    Linux 平台上需要开启 CAPSYSNICE 特性。比如我机器上用systemd 给mysql 服务加上

    systemctl edit mysql@80 [Service]AmbientCapabilities=CAP_SYS_NICE

    mysql 线程池开启后RG失效。

    freebsd,solaris 平台thread_priority 失效。

    目前只能绑定CPU,不能绑定其他资源。

温馨提示:答案为网友推荐,仅供参考
第1个回答  推荐于2017-11-23

可以用乐观锁方案解决

    在表里增加个字段,版本号

    每次更新前先从数据库里获取这个版本号的值,然后更新时要同步更新版本号+1,并且增加更新条件版本号=查询出来的值。

    因为更新时每次只可能有一个线程更新到数据,等到另外一个线程再去更新数据的时候版本号已经+1了,所以会更新失败,重新获取版本号再走更新流程,这样就解决了多线程并发更新被覆盖的问题。

    而且乐观锁机制避免了长事务中的数据库加锁开销(多个线程操作过程中,都没有对数据库数据加锁),大大提升了大并发量下的系统整体性能表现。

追问

那如何并发相当大,有两个或多个线程在同一个时间获取到版本号相同怎么办?这不同样会出现覆盖的问题吗?

追答

就算有多个线程都取到了相同的版本号,也不会出现更新被覆盖的问题。
假设取到的版本号为1,更新语句中限制条件where版本号=1,这样只会有一个线程更新成功,因为这个线程更新成功后版本号就会变成2,那其他线程通过条件版本号=1去更新就失败了,所以不会出现更新被覆盖的问题

本回答被提问者和网友采纳
相似回答