腾讯云开发者社区-腾讯云

开发者社区

文档建议反馈控制台

文章/答案/技术大牛

发布

综合排序丨最热优先丨最新优先

MYSQL（无表锁）行锁内存表引擎FASTMEM —— 让 MySQLMariaDB 的内存表不再“一锁到底“

是一个彻底没有表锁、读者无锁、写者按行串行化的内存存储引擎插件,把它装进MySQL/MariaDB,ENGINE=FASTMEM的内存表就能在高并发读写下碾压内置MEMORY(heap)表,甚至比InnoDB 线11.8LTS(11.8.6/11.8.9)fastmem-mariadb118上游项目MariaDB12.xfastmem为什么内存表“应该很快,却一锁到底”? 内存表数据全在内存,本该是闪电速度——但内置MEMORY(heap)引擎有一个致命设计:任何写操作都要先拿整表锁。 FASTMEM三大核心零表锁——store_lock()返回零个THR_LOCK_DATA,锁等待队列彻底不存在;无锁读者(seqlock)——读者复制行镜像,靠奇/偶序号校验、撕裂即重试;读者永不阻塞写者 (heap)7s61s62sInnoDB32s131s129s读者0→8递增时,FASTMEM写者几乎不退化(无锁读直接兑现):MariaDB上1s→2s,而MEMORY因整表锁被读者拖到同样2s起步。

2026-09-06

1490

标签:

FASTMEM 完成 MariaDB 12.3.3 适配:Linux Windows 双平台实测通过,正式发布 v1.0-mariadb123

开源内存存储引擎FASTMEM于今日宣布完成对MariaDB12.3.3的适配,并已在Linux与Windows两个平台完成端到端实测,同步发布v1.0版本。一、事件背景:一次随主干版本推进的适配MariaDB12.3系列于近期进入维护周期,作为社区维护的开源引擎插件,FASTMEM的核心代码需要跟随服务端API的演进进行适配。 FASTMEM的维护方表示,适配以MariaDB12.3.3官方storage/heap/hp_hash.c中MEMORY引擎的哈希实现为基准,按逐位等价的方式迁移了两个哈希散列函数;由于引擎与服务器共用同一套哈希语义 ,经此迁移后的FASTMEM表与官方MEMORY表在键值行为上保持一致。四、关于FASTMEMFASTMEM是一个面向MySQLMariaDB的内存存储引擎插件,以"无表锁、无锁读、行级写"为设计核心:对外不注册任何表级锁,读者通过seqlock无锁复制行镜像,写者按行槽与哈希桶自旋锁进行串行化

2026-09-14

1740

标签:

MySQL - 无索引行锁升级为表锁

---- ---- 无索引行锁升级为表锁演示表结构 mysql> desc country; +-------------+--------------+------+-----+---------+ --+-------------+----------+--------+------+------------+---------+---------------+ 1 row in set 这个表， anotherline’ ; ---- 一直被阻塞，直到超时 1205 - Lock wait timeout exceeded; try restarting transaction 我们知道锁主要是加在索引上，如果对非索引字段更新，行锁可能会变表锁 , 从上面的测试中也可以验证这个观点，第二个 ---- 结论 InnoDB的行锁是针对索引加的锁，不是针对记录加的锁 ,并且该索引不能失效，否则会从行锁升级为表锁所以建表的时候，结合你的业务，如果有更新的操作，切记要对操作的字段建立索引，不然并发下这个问题就非常明显了

2021-08-17

3.1K0

标签:

共享内存无锁队列的实现

作者：范健导语：共享内存无锁队列是老调重弹了，相关的实现网上都能找到很多。但看了公司内外的很多实现，都有不少的问题，于是自己做了重新实现。主要是考虑了一些异常情况加强健壮性，并且考虑了C++11的内存模型。为什么需要共享内存无锁队列？又因为业务模块可能是多线程模式也可能是多进程模式，所以队列应该是在共享内存中。简单的做法是，对队列的读写都加锁，但这样无疑会导致高并发下性能瓶颈就在这把锁上。所以我们需要无锁队列。看了公司内外很多版本的无锁队列实现，多多少少都有些问题，所以自己重新实现了一个版本。环形数组大部分无锁队列都是用环形数组实现的，简单高效，这里也不例外。共享内存另外一个值得一提的点是，共享内存我使用mmap，而非shmget。因为担心一台机器上部署的程序太多，可能出现共享内存key冲突的情况。

豆豆的包包

2017-11-06

13.4K0

标签:

PHP无锁内存nosql---Yac的实战

无锁内存nosql---Yac的实战　　最近在工作使用了yac,所以比较了下Memcache和Yac的高并发读写性能测试，发现Yac要比Memcache快很多（这里没有比较Yac和Apc的性能情况, 首先说下，Yac是无锁的、共享内存的Cache，因此可以减少CPU的消耗，而Memcache压力测试时CPU直接飙升到 ~100%。。。。　　 yac.keys_memory_size = 4M //4M可以得到32768个key， 32M可以得到262144个key yac.values_memory_size = 64M //申请的最大value内存让PHP进程之间共享一些简单的数据高效地缓存一些页面结果 Yac的限制缓存的键长度不能超过48字节，太长的话可以md5结果后再使用 Value的最大长度不能超过64M，压缩后的长度不能超过1M 当内存不够的时候 , Yac会有比较明显的踢出率 (所以如果要使用Yac, 那么尽量多给点内存...)

2020-08-20

1.6K1

标签:

一种高效无锁内存队列的实现

Disruptor是LMAX公司开源的一个高效的内存无锁队列。这两天看了一下相关的设计文档和博客，下面尝试进行一下总结。第一部分。引子谈到并发程序设计，有几个概念是避免不了的。好，接下来谈一谈设计并发内存队列时需要考虑的问题。在数组创建时可以预先分配好空间，插入新元素时只要将新元素数据拷贝到已经分配好的内存中即可。对数组的元素访问对CPU cache 是非常友好的。在一个生产者和一个消费者的场景中测试表明，无锁队列相比有锁队列，qps有大约10倍的提升，latency更是有几百倍的提升。不管怎么样，现在大家都渐渐都这么一个意识了：锁是性能杀手。所以这些无锁的数据结构和算法，可以尝试借鉴来使用在合适的场景中。

2018-03-23

5K1

标签:

三分钟入门 InnoDB 存储引擎中的表锁和行锁

需要注意的是，每种数据库对于锁的实现都是不同的，并且对于 MySQL 来说，每种存储引擎都可以实现自己的锁策略和锁粒度，比如 InnoDB 引擎支持行锁和表锁，而 MyISAM 引擎只支持表锁。表锁与行锁所谓 “表锁（Table Lock）”，就是会锁定整张表，它是 MySQL 中最基本的锁策略，并不依赖于存储引擎，就是说不管你是 MySQL 的什么存储引擎，对于表锁的策略都是一样的，并且表锁是开销最小的策略意向锁 InnoDB 存储引擎支持多粒度（granular）锁定，就是说允许事务在行级上的锁和表级上的锁同时存在。有两种意向锁：意向共享锁（IS Lock）：当事务想要获得一张表中某几行的共享锁行级锁）时，InnoDB 存储引擎会自动地先获取该表的意向共享锁（表级锁）意向排他锁（IX Lock）：当事务想要获得一张表中某几行的排他锁（行级锁）时，InnoDB 存储引擎会自动地先获取该表的意向排他锁（表级锁）各位其实可以直接把 ”意向“ 翻译成 ”想要“，想要共享锁、想要排他锁，你就会发现原来就这东西啊（滑稽）。

飞天小牛肉

2021-07-21

4.6K0

标签:

云数据库 SQL Server

关于使用MySQL innoDB引擎中事务和锁的信息记录表

innodb_trx,innodb_locks, innodb_lock_waits 通过这三张表用户可以更简单的去查看数据库中的锁问题。 1. information_schemma.INNODB_TRX 此表是查看当前运行的事务表中对应的字段说明见下图 ? 2. information_schema.INNODB_LOCKS innodb_trx可以查看到事务大概运行情况但是不能查看他具体的锁详情，那么我们就可以通过他trx表中的等待事务锁id去locks 表查找当前被锁住的id 或者根据事务来查看当前事务的锁的状态详情 ? 3.information_schema.INNODB_LOCKS_WAITS 这个表可以让用户清楚的看到那个事务阻塞了那个事务，但是这里只给出事务ID，没有更详细的锁信息，但是lock_waits这张表和

袁新栋-jeff.yuan

2020-08-26

2.9K0

标签:

云数据库 SQL Server

深入拆解 Java volatile：从内存屏障到无锁编程的实战指南

五、volatile在无锁编程中的应用除了单例模式，volatile在无锁编程中也有广泛的应用。无锁编程是指不使用synchronized等锁机制，而是利用CAS、volatile等机制实现线程安全的编程方式，它的性能通常比锁机制更好。 5.1状态标记状态标记是volatile最常见的无锁编程应用场景之一。比如我们可以用一个volatile变量来标记某个操作是否完成，其他线程通过这个变量来判断是否可以继续执行。一个线程写，多个线程读的场景：volatile最适合这种场景，因为它能保证写操作对所有读操作的可见性，同时性能比锁机制更好。本文从并发编程的三大问题入手，详细讲解了volatile的核心特性、底层实现原理，并结合单例模式、无锁编程等场景，介绍了volatile的正确使用方法。

果酱带你啃AI

2026-04-09

4720

标签:

深入理解C++11原子操作：从内存模型到无锁编程

原子操作作为无锁编程的基础，为高性能并发提供了可能，但也因其对内存模型的依赖而成为最容易误用的特性之一。 flag(false); // 布尔原子变量 std::atomic<MyStruct*> ptr(nullptr); // 指针原子变量可通过atomic_is_lock_free检查操作是否真正无锁 double is lock-free: " << std::atomic<double>{}.is_lock_free() << std::endl; 注意：在某些平台上，double类型的原子操作可能不是无锁的比较并交换（CAS） CAS是无锁编程的基石，操作逻辑为："如果当前值等于预期值，则替换为新值，否则不做修改"。案例2：基于CAS的无锁栈 #include <atomic> #include <iostream> template<typename T> class LockFreeStack { private

2025-07-02

9450

标签:

腾讯技术创作特训营S14#新手村