返回顶部
首页 > 资讯 > 数据库 >MySQL找出未提交事务的SQL实例浅析
  • 926
分享到

MySQL找出未提交事务的SQL实例浅析

mysql数据库事务mysql提交事务mysql事务sql 2022-05-19 15:05:20 926人浏览 八月长安
摘要

很久之前曾经总结过一篇博客“Mysql如何找出未提交事务信息”,现在看来,这篇文章中不少知识点或观点都略显肤浅,或者说不够深入,甚至部分结论是错误的。下面重新探讨一下这个话题。那么我们还是以之前的例子来介绍。 --准

很久之前曾经总结过一篇博客“Mysql如何找出未提交事务信息”,现在看来,这篇文章中不少知识点或观点都略显肤浅,或者说不够深入,甚至部分结论是错误的。下面重新探讨一下这个话题。那么我们还是以之前的例子来介绍。

--准备测试环境数据(实验环境为mysql 8.0.18社区版)


mysql> create table kkk(id int , name varchar(12));
Query OK, 0 rows affected (0.34 sec)
 
mysql> insert into kkk values(1, 'kerry');
Query OK, 1 row affected (0.01 sec)
 
mysql> insert into kkk values(2, 'jerry');
Query OK, 1 row affected (0.00 sec)
 
mysql> insert into kkk values(3, 'ken');
Query OK, 1 row affected (0.00 sec)
 
mysql> 
 
mysql> create table t(a varchar(10));
Query OK, 0 rows affected (0.47 sec)
 
mysql> insert into t values('test');
Query OK, 1 row affected (0.00 sec)

在一个会话窗口(连接ID=38)执行下面SQL


mysql> select connection_id() from dual;
+-----------------+
| connection_id() |
+-----------------+
|  38 |
+-----------------+
1 row in set (0.00 sec)
 
mysql> set session autocommit=0;
Query OK, 0 rows affected (0.00 sec)
 
mysql> delete from kkk where id =1;
Query OK, 1 row affected (0.00 sec)
 
mysql> 

在另外一个会话窗口(连接ID=39)执行下面SQL


mysql> SELECT t.trx_mysql_thread_id
 -> ,t.trx_id
 -> ,t.trx_state
 -> ,t.trx_tables_in_use
 -> ,t.trx_tables_locked
 -> ,t.trx_query
 -> ,t.trx_rows_locked 
 -> ,t.trx_rows_modified
 -> ,t.trx_lock_structs
 -> ,t.trx_started
 -> ,t.trx_isolation_level
 -> ,p.time 
 -> ,p.user
 -> ,p.host
 -> ,p.db
 -> ,p.command
 -> FROM infORMation_schema.innodb_trx t 
 -> INNER JOIN information_schema.processlist p 
 ->  ON t.trx_mysql_thread_id = p.id 
 -> WHERE t.trx_state = 'RUNNING' 
 -> AND p.time > 4 
 -> AND p.command = 'Sleep'\G 
*************************** 1. row ***************************
trx_mysql_thread_id: 38
  trx_id: 7981581
  trx_state: RUNNING
 trx_tables_in_use: 0
 trx_tables_locked: 1
  trx_query: NULL
 trx_rows_locked: 4
 trx_rows_modified: 1
 trx_lock_structs: 2
 trx_started: 2020-12-03 15:39:37
trx_isolation_level: REPEATABLE READ
  time: 23
  user: root
  host: localhost
   db: MyDB
  command: Sleep
1 row in set (0.00 sec)

虽然上面这个SQL找不出事务执行过的SQL,其实呢,MySQL中未提交事务的最后执行的一个SQL是可以通过下面脚本准确查找出来的。如下所示:


SELECT t.trx_mysql_thread_id   AS connection_id
 ,t.trx_id     AS trx_id  
 ,t.trx_state     AS trx_state 
 ,t.trx_started    AS trx_started 
 ,TIMESTAMPDIFF(SECOND,t.trx_started, now()) AS "trx_run_time(s)" 
 ,t.trx_requested_lock_id   AS trx_requested_lock_id
 ,t.trx_operation_state   AS trx_operation_state
 ,t.trx_tables_in_use    AS trx_tables_in_use
 ,t.trx_tables_locked    AS trx_tables_locked
 ,t.trx_rows_locked    AS trx_rows_locked
 ,t.trx_isolation_level   AS trx_isolation_level
 ,t.trx_is_read_only    AS trx_is_read_only
 ,t.trx_autocommit_non_locking   AS trx_autocommit_non_locking
 ,e.event_name     AS event_name
 ,e.timer_wait / 1000000000000   AS timer_wait
 ,e.sql_text 
FROM information_schema.innodb_trx t, 
 performance_schema.events_statements_current e, 
 performance_schema.threads c 
WHERE t.trx_mysql_thread_id = c.processlist_id 
 AND e.thread_id = c.thread_id\G;

如下截图所示:

在会话窗口(连接ID=38)继续执行下面SQL:"select * from t;"。 如下所示


mysql> set session autocommit=0;
Query OK, 0 rows affected (0.01 sec)
 
mysql> delete from kkk where id =1;
Query OK, 1 row affected (0.00 sec)
 
mysql> select * from t;
+------+
| a |
+------+
| test |
+------+
1 row in set (0.00 sec)
 
mysql> 

在会话窗口(连接ID=39)上继续执行下面SQL,你会发现捕获的是事务最后执行的SQL语句“select * from t”


mysql> SELECT t.trx_mysql_thread_id   AS connection_id
 -> ,t.trx_id     AS trx_id  
 -> ,t.trx_state     AS trx_state 
 -> ,t.trx_started    AS trx_started 
 -> ,TIMESTAMPDIFF(SECOND,t.trx_started, now()) AS "trx_run_time(s)" 
 -> ,t.trx_requested_lock_id   AS trx_requested_lock_id
 -> ,t.trx_operation_state   AS trx_operation_state
 -> ,t.trx_tables_in_use    AS trx_tables_in_use
 -> ,t.trx_tables_locked    AS trx_tables_locked
 -> ,t.trx_rows_locked    AS trx_rows_locked
 -> ,t.trx_isolation_level   AS trx_isolation_level
 -> ,t.trx_is_read_only    AS trx_is_read_only
 -> ,t.trx_autocommit_non_locking   AS trx_autocommit_non_locking
 -> ,e.event_name     AS event_name
 -> ,e.timer_wait / 1000000000000   AS timer_wait
 -> ,e.sql_text 
 -> FROM information_schema.innodb_trx t, 
 -> performance_schema.events_statements_current e, 
 -> performance_schema.threads c 
 -> WHERE t.trx_mysql_thread_id = c.processlist_id 
 -> AND e.thread_id = c.thread_id\G; 
*************************** 1. row ***************************
  connection_id: 38
   trx_id: 7981581
   trx_state: RUNNING
  trx_started: 2020-12-03 15:39:37
  trx_run_time(s): 237
 trx_requested_lock_id: NULL
 trx_operation_state: NULL
  trx_tables_in_use: 0
  trx_tables_locked: 1
  trx_rows_locked: 4
 trx_isolation_level: REPEATABLE READ
  trx_is_read_only: 0
trx_autocommit_non_locking: 0
  event_name: statement/sql/select
  timer_wait: 0.0002
   sql_text: select * from t
1 row in set (0.00 sec)
 
ERROR: 
No query specified

也是说上面SQL只能获取未提交事务最后执行的一个SQL语句,生产环境中,一个事务中往往不止一个SQL语句,而是多个SQL语句的集合。如果想将一个未提交事务里面所有执行过的SQL找出来怎么办呢?其实在MySQL中还是有办法的。下面SQL语句就可以找出或者


SELECT trx.trx_mysql_thread_id AS processlist_id
 ,sc.thread_id
 ,trx.trx_started
 ,TO_SECONDS(now())-TO_SECONDS(trx_started) AS trx_last_time 
 ,pc1.user
 ,pc1.host
 ,pc1.db
 ,sc.SQL_TEXT AS current_sql_text
 ,sh.history_sql_test
FROM INFORMATION_SCHEMA.INNODB_TRX trx
INNER JOIN INFORMATION_SCHEMA.processlist pc1 ON trx.trx_mysql_thread_id=pc1.id
INNER JOIN performance_schema.threads th on th.processlist_id = trx.trx_mysql_thread_id
INNER JOIN performance_schema.events_statements_current sc ON sc.THREAD_ID = th.THREAD_ID
INNER JOIN (
  SELECT thread_id AS thread_id, GROUP_CONCAT(SQL_TEXT SEPARATOR ';') AS history_sql_test
  FROM performance_schema.events_statements_history 
  GROUP BY thread_id 
  ) sh ON sh.thread_id = th.thread_id
WHERE trx_mysql_thread_id != connection_id()
 AND TO_SECONDS(now())-TO_SECONDS(trx_started) >= 0 ;

但是这两个SQL有个问题:它会找出当前连接历史上所有执行过的SQL(当然前提是这些SQL还保存在performance_schema.events_statements_history表中),也就是说这个SQL,不仅查询出未提交事务所有执行过的脚本,而且会查询出很多历史SQL脚本,例如,这个会话(连接)之前事务的SQL语句,而且还有一个比较头疼的问题:这里不好区分哪些SQL对应哪些事务。需要借助其他信息来甄别。比较费时费力。如下截图所示。

因为只有information_schema.innodb_trx系统表中包含事务的开始时间(trx_started),其它系统表没有跟事务相关的时间,只能借助performance_schema.events_statements_history中的TIMER_START字段来获取事件的SQL开始执行的时间,而这个时间必然是小于或等于对应事务的开始时间(trx_started)的。所以从这个突破口来找出未提交事务的所有SQL,下面是关于TIMER_START等字段的详细介绍。

关于TIMER_START,TIMER_END,TIMER_WAIT的介绍如下:

TIMER_START,TIMER_END,TIMER_WAIT:事件的时间信息。这些值的单位是皮秒(万亿分之一秒)。

TIMER_START和TIMER_END值表示事件的开始时间和结束时间。

TIMER_WAIT是事件执行消耗的时间(持续时间)

如果事件未执行完成,则TIMER_END为当前时间,TIMER_WAIT为当前为止所经过的时间(TIMER_END - TIMER_START)。

如果监视仪器配置表setup_instruments中对应的监视器TIMED字段被设置为 NO,则不会收集该监视器的时间信息,那么对于该事件采集的信息记录中,TIMER_START,TIMER_END和TIMER_WAIT字段值均为NULL

测试、折腾了好久,终于搞出了一个几乎完美的SQL:


SELECT @dt_ts:=UNIX_TIMESTAMP(NOW());
SELECT 
 @dt_timer:=MAX(sh.TIMER_START)
FROM performance_schema.threads AS t
INNER JOIN performance_schema.events_statements_history AS sh
ON t.`THREAD_ID`=sh.`THREAD_ID`
WHERE t.PROCESSLIST_ID=CONNECTION_ID();
 
 
SELECT sh.current_schema  AS database_name
 ,t.thread_id
 ,it.trx_mysql_thread_id  AS connection_id
 ,it.trx_id
 ,sh.event_id
 ,it.trx_state
 ,REPLACE(REPLACE(REPLACE(sh.`SQL_TEXT`,'\n',' '),'\r',' '),'\t',' ') AS executed_sql
 ,it.trx_started
 ,FROM_UNIXTIME(@dt_ts-CAST((@dt_timer-sh.TIMER_START)/1000000000000 AS SIGNED)) AS start_time
 ,FROM_UNIXTIME(@dt_ts-CAST((@dt_timer-sh.TIMER_END) /1000000000000 AS SIGNED)) AS end_time
 ,(sh.TIMER_END-sh.TIMER_START)/1000000000000 AS used_seconds
 ,sh.TIMER_WAIT/1000000000000 AS wait_seconds
 ,sh.LOCK_TIME/1000000000000 AS lock_seconds
 ,sh.ROWS_AFFECTED AS affected_rows
 ,sh.ROWS_SENT AS send_rows
FROM performance_schema.threads AS t
INNER JOIN information_schema.innodb_trx it ON it.trx_mysql_thread_id = t.processlist_id 
INNER JOIN performance_schema.events_statements_history AS sh
 ON t.`THREAD_ID`=sh.`THREAD_ID`
WHERE t.PROCESSLIST_ID IN (
  SELECT 
   p.ID AS conn_id
  FROM `information_schema`.`INNODB_TRX` t
  INNER JOIN `information_schema`.`PROCESSLIST` p
   ON t.trx_mysql_thread_id=p.id
  WHERE t.trx_state='RUNNING'
   AND p.COMMAND='Sleep'
   AND p.TIME>2
  )
AND sh.TIMER_START<@dt_timer
AND FROM_UNIXTIME(@dt_ts-CAST((@dt_timer-sh.TIMER_START)/1000000000000 AS SIGNED)) >=it.trx_started
ORDER BY it.trx_id ASC, sh.TIMER_START ASC;

它能找出未提交事务的SQL,简单测试完全没有问题,同时构造几个未提交事务测试也OK。但是上面SQL由三个SQL组成,总感觉有点别扭,研究了一下,可以改造成下面SQL。


SELECT sh.current_schema  AS database_name
 ,t.thread_id
 ,it.trx_mysql_thread_id AS connection_id
 ,it.trx_id
 ,sh.event_id
 ,it.trx_state
 ,REPLACE(REPLACE(REPLACE(sh.`SQL_TEXT`,'\n',' '),'\r',' '),'\t',' ') AS executed_sql
 ,it.trx_started
 ,DATE_SUB(NOW(), INTERVAL (SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME='UPTIME') - sh.TIMER_START*10e-13 second) AS start_time
 ,DATE_SUB(NOW(), INTERVAL (SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME='UPTIME') - sh.TIMER_END*10e-13 second) AS end_time
 ,(sh.TIMER_END-sh.TIMER_START)/1000000000000 AS used_seconds
 ,sh.TIMER_WAIT/1000000000000 AS wait_seconds
 ,sh.LOCK_TIME/1000000000000 AS lock_seconds
 ,sh.ROWS_AFFECTED AS affected_rows
 ,sh.ROWS_SENT AS send_rows
FROM performance_schema.threads AS t
INNER JOIN information_schema.innodb_trx it ON it.trx_mysql_thread_id = t.processlist_id 
INNER JOIN performance_schema.events_statements_history AS sh
 ON t.`THREAD_ID`=sh.`THREAD_ID`
WHERE t.PROCESSLIST_ID IN (
  SELECT 
   p.ID AS conn_id
  FROM `information_schema`.`INNODB_TRX` t
  INNER JOIN `information_schema`.`PROCESSLIST` p
   ON t.trx_mysql_thread_id=p.id
  WHERE t.trx_state='RUNNING'
   AND p.COMMAND='Sleep'
   AND p.TIME>2
  )
AND sh.TIMER_START<(SELECT VARIABLE_VALUE*1000000000000 FROM performance_schema.global_status WHERE VARIABLE_NAME='UPTIME')
AND DATE_SUB(NOW(), INTERVAL (SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME='UPTIME') - sh.TIMER_START*10e-13 second) >=it.trx_started
ORDER BY it.trx_id ASC, sh.TIMER_START ASC;

注意:performance_schema.global_status是MySQL 5.7引入的,如果数据库是MySQL 5.6的话,可以用INFORMATION_SCHEMA.GLOBAL_STATUS替换SQL中的performance_schema.global_status

那么是否这个SQL就一定完美了呢? 网友MSSQL123反馈在一个测试环境中,发现上面这种SQL居然查不出任何数据,因为FROM_UNIXTIME(@dt_ts-CAST((@dt_timer-sh.TIMER_START)/1000000000000 AS SIGNED)) >=it.trx_started会将数据过滤掉,检查发现对应的trx_started值都大于start_time

-------------------------------------------------------------------------补充资料--------------------------------------------------------------------------------------------------------

那么同一个测试环境,隔天测试的时候,突然发现上面第一个SQL正常,第二个SQL就由于不同的写法,start_time有细微的差别,导致查询结果完全不同(第二个SQL语句精确到毫秒,对比的时候由于偏差过滤掉一批数据)

------------------------------------------------------------------------------------------------------------------------------------------------

搜索相关文档,了解到TIMER_START字段值可能有波动或偏差,那么这个波动或偏差可能影响查询结果,下面内容来自Http://porthos.ist.utl.pt/docs/mySQL/performance-schema.html

Modifications to the setup_timers table affect monitoring immediately. Events already in progress may use the original timer for the begin time and the new timer for the end time. To avoid unpredictable results after you make timer changes, use TRUNCATE TABLE to reset Performance Schema statistics.

The timer baseline (“time zero”) occurs at Performance Schema initialization during server startup. TIMER_START and TIMER_END values in events represent picoseconds since the baseline. TIMER_WAIT values are durations in picoseconds.

Picosecond values in events are approximate. Their accuracy is subject to the usual forms of error associated with conversion from one unit to another. If the CYCLE timer is used and the processor rate varies, there might be drift. For these reasons, it is not reasonable to look at the TIMER_START value for an event as an accurate measure of time elapsed since server startup. On the other hand, it is reasonable to use TIMER_START or TIMER_WAIT values in ORDER BY clauses to order events by start time or duration.

The choice of picoseconds in events rather than a value such as microseconds has a performance basis. One implementation Goal was to show results in a uniform time unit, regardless of the timer. In an ideal world this time unit would look like a wall-clock unit and be reasonably precise; in other Words, microseconds. But to convert cycles or nanoseconds to microseconds, it would be necessary to perform a division for every instrumentation. Division is expensive on many platforms. Multiplication is not expensive, so that is what is used. Therefore, the time unit is an integer multiple of the highest possible TIMER_FREQUENCY value, using a multiplier large enough to ensure that there is no major precision loss. The result is that the time unit is “picoseconds.” This precision is spurious, but the decision enables overhead to be minimized.

Before MySQL 5.7.8, while a wait, stage, statement, or transaction event is executing, the respective current-event tables display the event with TIMER_START populated, but with TIMER_END and TIMER_WAIT set to NULL

其中一段内容翻译如下:

事件中的皮秒值是近似值。它们的准确性受与从一个单位转换到另一单位相关的常见误差形式的影响。如果使用了CYCLE定时器,并且处理器速率有所变化,则可能会有偏差。由于这些原因,将事件的TIMER_START值视为自服务器启动以来经过的时间的准确度量是不合理的。另一方面,在ORDER BY子句中使用TIMER_START或TIMER_WAIT值来按开始时间或持续时间对事件进行排序是合理的。

我们往往想一击必杀的解决问题,但是由于复杂的环境和一些不可控因素,现实往往就是“没有银弹”这么残酷。如果遇到TIMER_START的波动或偏差影响查询结果时,那么我们必须通过文章前面的SQL找出大量SQL,然后通过其它字段或信息人工甄别哪些才是未提交事务的SQL。

参考资料:

https://stackoverflow.com/questions/25607249/mysql-performance-schema-how-to-get-event-time-from-events-statements-current-ta

http://porthos.ist.utl.pt/docs/mySQL/performance-schema.html

https://dev.mysql.com/doc/refman/5.7/en/performance-schema-timing.html

https://dev.mysql.com/doc/refman/8.0/en/performance-schema-timing.html

到此这篇关于MySQL找出未提交事务SQL的文章就介绍到这了,更多相关MySQL找出未提交事务SQL内容请搜索自学编程网以前的文章或继续浏览下面的相关文章希望大家以后多多支持自学编程网!

您可能感兴趣的文档:

--结束END--

本文标题: MySQL找出未提交事务的SQL实例浅析

本文链接: https://lsjlt.com/news/10013.html(转载时请注明来源链接)

有问题或投稿请发送至: 邮箱/279061341@qq.com    QQ/279061341

猜你喜欢
  • MySQL找出未提交事务的SQL实例浅析
    很久之前曾经总结过一篇博客“MySQL如何找出未提交事务信息”,现在看来,这篇文章中不少知识点或观点都略显肤浅,或者说不够深入,甚至部分结论是错误的。下面重新探讨一下这个话题。那么我们还是以之前的例子来介绍。 --准...
    99+
    2022-05-19
    mysql数据库事务 mysql提交事务 mysql 事务sql
  • 找出未提交的MySQL线程/事务
    找出未提交的MySQL线程/事务:SELECT * from information_schema.processlist;   这个能看到上面哪个SQL线程ID(下图的378号线程就是造...
    99+
    2024-04-02
  • 怎么在MySQL中找出未提交的事务信息
    本篇文章给大家分享的是有关怎么在MySQL中找出未提交的事务信息,小编觉得挺实用的,因此分享给大家学习,希望大家阅读完这篇文章后可以有所收获,话不多说,跟着小编一起来看看吧。mysql> s...
    99+
    2024-04-02
  • ORACLE中怎么找到未提交事务的SQL语句
    这篇文章主要介绍了ORACLE中怎么找到未提交事务的SQL语句,具有一定借鉴价值,感兴趣的朋友可以参考下,希望大家阅读完这篇文章之后大有收获,下面让小编带着大家一起了解一下。在Oracle数据库中,我们能否...
    99+
    2024-04-02
  • MySQL通过performance_schema定位未提交事务所执行的SQL
    经常会遇到这样一个场景: 业务那边觉得数据库“很慢”,上去通过show processlist查看发现大量State为在等待lock,如: Waiting for table metadata/level ...
    99+
    2024-04-02
  • MySQL未提交事务造成的等待事件怎么解决
    本篇内容主要讲解“MySQL未提交事务造成的等待事件怎么解决”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“MySQL未提交事务造成的等待事件怎么解决”吧! ...
    99+
    2024-04-02
  • 浅谈MySQL中是如何实现事务提交和回滚的
    目录什么是事务redo logundo log总结一下什么是事务 事务是由数据库中一系列的访问和更新组成的逻辑执行单元 事务的逻辑单元中可以是一条SQL语句,也可以是一段SQL逻辑,...
    99+
    2024-04-02
  • mysql实现事务的提交与回滚的实例详解
    最近要对数据库的数据进行一个定时迁移,为了防止在执行过程sql语句因为某些原因报错而导致数据转移混乱,因此要对我们的脚本加以事务进行控制。 首先我们建一张tran_test表 CREATE TABLE ...
    99+
    2024-04-02
  • Mysql事务隔离级别之读提交的示例分析
    这篇文章主要为大家展示了“Mysql事务隔离级别之读提交的示例分析”,内容简而易懂,条理清晰,希望能够帮助大家解决疑惑,下面让小编带领大家一起研究并学习一下“Mysql事务隔离级别之读提交的示例分析”这篇文...
    99+
    2024-04-02
  • golang实现mysql数据库事务的提交与回滚
    MySQL 事务主要用于处理操作量大,复杂度高的数据。在 MySQL 中只有使用了 Innodb 数据库引擎的数据库或表才支持事务。 事务用来管理 insert,update...
    99+
    2024-04-02
  • 出现未将对象引用设置到对象的实例提示是怎么回事
    这个错误提示通常是在编程中出现的,表示在尝试使用一个未初始化或者为null的对象引用时触发了错误。常见的原因有:1. 未初始化对象:...
    99+
    2023-09-21
    对象
  • Sql Server事务语法及使用方法的实例分析
    这篇文章将为大家详细讲解有关Sql Server事务语法及使用方法的实例分析,文章内容质量较高,因此小编分享给大家做个参考,希望大家阅读完这篇文章后对相关知识有一定的了解。实例讲述了Sql Server事务...
    99+
    2024-04-02
  • 怎么在golang中实现mysql数据库事务的提交与回滚
    这期内容当中小编将会给大家带来有关怎么在golang中实现mysql数据库事务的提交与回滚,文章内容丰富且以专业的角度为大家分析和叙述,阅读完这篇文章希望大家可以有所收获。golang适合做什么golang可以做服务器端开发,但golang...
    99+
    2023-06-14
  • mysql的计划任务与事件调度实例分析
    本文实例讲述了mysql的计划任务与事件调度。分享给大家供大家参考,具体如下: mysql事件是基于预定义的时间表运行的任务,因此有时它被称为预定事件。mysql事件也被称为“时间触发”,因为它是由时间触发...
    99+
    2024-04-02
  • MySQL事务的ACID特性及并发问题实例分析
    本篇内容主要讲解“MySQL事务的ACID特性及并发问题实例分析”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“MySQL事务的ACID特性及并发问题实例分析”吧...
    99+
    2024-04-02
  • MySQL事务隔离实现并发控制的示例分析
    这篇文章主要介绍了MySQL事务隔离实现并发控制的示例分析,具有一定借鉴价值,感兴趣的朋友可以参考下,希望大家阅读完这篇文章之后大有收获,下面让小编带着大家一起了解一下。一、并发访问控制实现的并发访问的控制技术是基于锁;锁分为表级锁和行级锁...
    99+
    2023-06-20
  • 在与 SQL Server 建立连接时出现与网络相关的或特定于实例的错误。未找到或无法访问服务器
    针对“在与 SQL Server 建立连接时出现与网络相关的或特定于实例的错误。未找到或无法访问服务器”的问题,可以采取以下步骤进行排除: 1. 检查网络连接 首先,需要确保计算机与 SQL Server 数据库服务器之间建立了正确的网络连...
    99+
    2023-09-14
    服务器 运维
  • mysql中如何实现定位空闲会话事务没提交导致锁阻塞的脚本
    这篇文章主要为大家展示了“mysql中如何实现定位空闲会话事务没提交导致锁阻塞的脚本”,内容简而易懂,条理清晰,希望能够帮助大家解决疑惑,下面让小编带领大家一起研究并学习一下“mysql中如何实现定位空闲会...
    99+
    2024-04-02
  • mysql中的事务隔离级别及可重复读读提交详细分析(mvcc多版本控制/undo log)
    一.事物隔离级别 读未提交(read uncommitted)是指,一个事务还没提交时,它做的变更就能被别的事务看到.通俗理解,别人改数据的事务尚未提交,我在我的事务中也能读到。 读提交(read committed)是指,一个...
    99+
    2015-03-04
    mysql中的事务隔离级别及可重复读读提交详细分析(mvcc多版本控制/undo log)
软考高级职称资格查询
编程网,编程工程师的家园,是目前国内优秀的开源技术社区之一,形成了由开源软件库、代码分享、资讯、协作翻译、讨论区和博客等几大频道内容,为IT开发者提供了一个发现、使用、并交流开源技术的平台。
  • 官方手机版

  • 微信公众号

  • 商务合作