首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

为什么修改数据库数据的查询是可等待的,而只读取数据的查询则不是?

修改数据库数据的查询是可等待的,而只读取数据的查询则不是的原因如下:

  1. 数据库的读取操作是幂等的:读取数据不会对数据本身产生任何影响,因此可以并发执行多个读取操作而不会产生冲突。多个读取操作可以同时进行,不需要等待其他读取操作的完成。
  2. 数据库的修改操作是非幂等的:修改数据会对数据本身产生变化,因此多个修改操作可能会产生冲突。为了保证数据的一致性,数据库系统会对修改操作进行加锁,确保每次修改操作的执行顺序和结果是可预测的。当一个修改操作正在执行时,其他修改操作需要等待该操作完成后才能执行,以避免数据冲突。
  3. 修改操作可能涉及到复杂的计算和数据更新:修改数据库数据可能需要执行复杂的计算逻辑和数据更新操作,这些操作可能会消耗较长的时间。为了避免长时间的等待,数据库系统可以将修改操作设置为可等待的,即提交修改请求后立即返回,然后在后台异步执行实际的修改操作。这样可以提高系统的并发性能和响应速度。

总结起来,修改数据库数据的查询是可等待的,因为修改操作可能会产生冲突,需要加锁保证数据的一致性,并且可能涉及到复杂的计算和数据更新操作,为了提高系统的并发性能和响应速度,可以将修改操作设置为可等待的。而只读取数据的查询是幂等的,可以并发执行多个读取操作,不需要等待其他读取操作的完成。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

  • 表空间的状态(二) - read/write

    1. 只读表空间的主要用途就是为了消除对数据库大部分静态数据的备份和恢复的需要。Oracle不会更新只读表空间爱你的文件,因此这部分文件可以存储于只读介质中,例如CD-ROM或WORM drives。 2. 只读表空间并不是为了满足归档的要求。只读表空间不能修改。如果需要修改只读表空间中的记录,则需要先将表空间置为read/write。更新表空间后,可以重置为只读。 3. 由于只读表空间不能修改,所以只要没有置为read/write,就不需要重复地进行备份。而且,如果需要恢复数据库时,也不需要恢复只读表空间,原因就是他们未曾修改过。 4. 能从只读表空间中删除对象,例如表或索引,但不能创建或修改对象。可以执行修改数据字典中文件描述的语句,例如ALTER TABLE ... ADD或ALTER TABLE ... MODIFY,但不能添加任何新的描述信息,除非表空间置为read/write。 5. 只读表空间可以导出导入到其他数据库。既然只读表空间不能修改,他们就能存储于CD-ROM或WORM(一次写-多次读)这些设施中。 6. 所有表空间初始创建都是read/write。使用READ ONLY子句可以设置表空间为只读。前提是必须具有ALTER TABLESPACE或MANAGE TABLESPACE的系统权限。 使用ALTER TABLESPACE ... READ ONLY前,需要满足以下条件: > 表空间处于online状态。这是为了确保不会有UNDO信息需要应用到表空间。注:如果处于offline,则会将UNDO信息存储于SYSTEM表空间,待恢复online时应用这些UNDO信息。 > 不能修改活动的UNDO表空间或SYSTEM表空间。 > 表空间不能处于当前正在进行的online备份中,因为备份结束时会更新表空间所有数据文件的头部信息。 > 为了让从只读表空间读取数据得到更好的性能,可以在置为read-only之前执行一次访问表空间的表中所有数据块的查询。一个像SELECT COUNT(*)这样简单的查询,就可以确保在表空间的数据块在接下来的访问中获得最佳的效率。因为这种做法就不需要数据库检查最近经常修改数据块的交易状态。 7. 可以在数据库正处理交易的时候执行ALTER TABLESPACE ... READ ONLY语句。执行语句后,表空间就处于交易只读状态。不会允许任何交易(DML操作)应用于表空间。如果尝试进行交易操作,那么此操作会被终止和回滚。然而,那些已经做了变更并不再进行进一步修改的交易,就允许执行commit或roll back操作。 如果ALTER TABLESPACE ... READ ONLY语句执行前,一个交易已经执行了,但是回滚到一个保存点,回滚了他对表空间的变更,那么ALTER TABLESPACE ... READ ONLY语句不会等待这个活动的交易。 8. 交易级只读状态仅仅当初始化参数COMPATIBLE是8.1.0或以上值时才能使用。如果参数值小于8.1.0,并且存在活动的交易,ALTER TABLESPACE ... READ ONLY语句会失败。 9. 如果ATLER TABLESPACE语句执行时间太长了,那么就需要找到阻止只读状态生效的那些交易。如下语句可以找出执行ALTER TABLESPACE ... RAED ONLY语句的交易入口和session地址(saddr): SELECT SQL_TEXT, SADDR FROM V$SQLAREA,V$SESSION WHERE V$SQLAREA.ADDRESS = V$SESSION.SQL_ADDRESS AND SQL_TEXT LIKE 'alter tablespace%'; SQL_TEXT                                  SADDR ---------------------------------------- -------- alter tablespace tbs1 read only           80034AF0 每个活动交易的开始SCN会存储于V$TRANSACTION视图中。起始SCN越小,说明这步操作就越早。潜在地这条语句越可能阻止接下来只读状态的变更。 SELECT SES_ADDR, START_SCNB FROM V$TRANSACTION ORDER BY START_SCNB; SES_ADDR START_SCNB -------- ---------- 800352A0 3621 --> waiting on this txn 80035A50 3623 --> waiting on this txn 80034AF0 3628 --> this is the ALTE

    02

    MySQL的并发控制 一文读懂!

    例如:以Unix系统的email box为例,典型的mbox文件格式是非常简单的。一个mbox邮箱中的所有邮件都串行在一起,彼此首尾相连。这种格式对于读取和分析邮件信息非常友好,同时投递邮件也很容易,只要在文件末尾附加新的邮件内容即可。但如果两个进程在同一时刻对同一个邮箱投递邮件,会发生什么情况?显然,邮箱的数据会被破坏,两封邮件的内容会交叉地附加在邮箱文件的末尾。设计良好的邮箱投递系统会通过锁(lock)来防止数据损坏。如果客户试图投递邮件,而邮箱已经被其他客户锁住,那就必须等待,直到锁释放才能进行投递。这种锁的方案在实际应用环境中虽然工作良好,但并不支持并发处理。因为在任意一个时刻,只有一个进程可以修改邮箱的数据,这在大容量的邮箱系统中是个问题。

    02
    领券