MySQL在并发场景下的问题及解决思路

1、配景

对付数据库体系来说在多用户并发前提下进步并发性的同时又要担保数据的同等性一向是数据库体系追求的方针，既要满意大量并发会见的需求又必需担保在此前提下数据的安详，为了满意这一方针大大都数据库通过锁和事宜机制来实现，MySQL数据库也不破例。尽量云云我们如故会在营业开拓进程中碰着各类百般的疑难题目，本文将以案例的方法演示常见的并发题目并说明办理思绪。

2、表锁导致的慢查询的题目

起首我们看一个简朴案例，按照ID查询一条用户信息：

mysql> select * from user where id=6; 

这个表的记录总数为3条，但却执行了13秒。

呈现这种题目我们起首想到的是看看当前MySQL历程状态：

从历程上可以看出select语句是在守候一个表锁，那么这个表锁又是什么查询发生的呢？这个功效中并没有表现直接的关联相关，但我们可以展望多数是那条update语句发生的（由于历程中没有其他可疑的SQL），为了印证我们的揣摩，先搜查一下user表布局：

公然user表行使了MyISAM存储引擎，MyISAM在执行操纵前会发生表锁，操纵完成再自动解锁。假如操纵是写操纵，则表锁范例为写锁，假如操纵是读操纵则表锁范例为读锁。正如和你领略的一样写锁将阻塞其他操纵(包罗读和写)，这使得全部操纵变为串行；而读锁环境下读-读操纵可以并行，但读-写操纵如故是串行。以下示例演示了显式指定了表锁（读锁），读-读并行，读-写串行的环境。

显式开启/封锁表锁，行使lock table user read/write; unlock tables;

session1：

session2：

可以看到会话1启用表锁（读锁）执行读操纵，这时会话2可以并行执行读操纵，但写操纵被阻塞。接着看：

session1：

session2：

当session1执行解锁后，seesion2则立即开始执行写操纵，即读-写串行。

总结：

到此我们把题目的缘故起因基天职析清晰，总结一下——MyISAM存储引擎执行操纵时会发生表锁，将影响其他用户对该表的操纵，假如表锁是写锁，则会导致其他用户操纵串行，假如是读锁则其他用户的读操纵可以并行。以是偶然我们碰着某个简朴的查询花了很长时刻，看看是不是这种环境。

办理步伐：

1）只管不消MyISAM存储引擎，在MySQL8.0版本中已经去掉了全部的MyISAM存储引擎的表，保举行使InnoDB存储引擎。

2）假如必然要用MyISAM存储引擎，镌汰写操纵的时刻；

3、线上修改表布局有哪些风险？

假若有一天营业体系必要增大一个字段长度，可否在线上直接修改呢？在答复这个题目前，我们先来看一个案例：

以上语句实行修改user表的name字段长度，语句被阻塞。凭证老例，我们搜查一下当前历程：

从历程可以看出alter语句在守候一个元数据锁，而这个元数据锁很也许是上面这条select语句引起的，事拭魅正是云云。在执行DML（select、update、delete、insert）操纵时，会对表增进一个元数据锁，这个元数据锁是为了担保在查询时代表布局不会被修改，因此上面的alter语句会被阻塞。那么假如执行次序相反，先执行alter语句，再执行DML语句呢？DML语句会被阻塞吗？譬喻我正在线上情形修改表布局，线上的DML语句会被阻塞吗？谜底是：不确定。

在MySQL5.6开始提供了online ddl成果，应承一些DDL语句和DML语句并发，在当前5.7版本对online ddl又有了加强，这使得大部门DDL操纵可以在线举办。详见：https://dev.mysql.com/doc/refman/5.7/en/innodb-create-index-overview.html

以是对付特定场景执行DDL进程中，DML是否会被阻塞必要视场景而定。

总结：通过这个例子我们对元数据锁和online ddl有了一个根基的熟悉，假如我们在营业开拓进程中有在线修改表布局的需求，可以参考以下方案：

1. 只管在营业量小的时刻段举办；

2. 查察官方文档，确认要做的表修改可以和DML并发，不会阻塞线上营业；

3. 保举行使percona公司的pt-online-schema-change器材，该器材被官方的online ddl更为强盛，它的根基道理是：通过insert… select…语句举办一次全量拷贝，通过触发器记录表布局改观进程中发生的增量，从而到达表布局改观的目标。

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!