找到
18
篇与
数据库
相关的结果
- 第 2 页
-
深入理解乐观锁与悲观锁 在数据库的锁机制中介绍过，数据库管理系统（DBMS）中的并发控制的任务是确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性。 乐观并发控制(乐观锁)和悲观并发控制（悲观锁）是并发控制主要采用的技术手段。 无论是悲观锁还是乐观锁，都是人们定义出来的概念，可以认为是一种思想。其实不仅仅是关系型数据库系统中有乐观锁和悲观锁的概念，像memcache、hibernate、tair等都有类似的概念。 针对于不同的业务场景，应该选用不同的并发控制方式。所以，不要把乐观并发控制和悲观并发控制狭义的理解为DBMS中的概念，更不要把他们和数据中提供的锁机制（行锁、表锁、排他锁、共享锁）混为一谈。其实，在DBMS中，悲观锁正是利用数据库本身提供的锁机制来实现的。 下面来分别学习一下悲观锁和乐观锁。 悲观锁 当我们要对一个数据库中的一条数据进行修改的时候，为了避免同时被其他人修改，最好的办法就是直接对该数据进行加锁以防止并发。 这种借助数据库锁机制在修改数据之前先锁定，再修改的方式被称之为悲观并发控制（又名“悲观锁”，Pessimistic Concurrency Control，缩写“PCC”）。 在关系数据库管理系统里，悲观并发控制（又名“悲观锁”，Pessimistic Concurrency Control，缩写“PCC”）是一种并发控制的方法。它可以阻止一个事务以影响其他用户的方式来修改数据。如果一个事务执行的操作都某行数据应用了锁，那只有当这个事务把锁释放，其他事务才能够执行与该锁冲突的操作。悲观并发控制主要用于数据争用激烈的环境，以及发生并发冲突时使用锁保护数据的成本要低于回滚事务的成本的环境中。 悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度(悲观)，因此，在整个数据处理过程中，将数据处于锁定状态。 悲观锁的实现，往往依靠数据库提供的锁机制 （也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据） 在数据库中，悲观锁的流程如下： 在对任意记录进行修改前，先尝试为该记录加上排他锁（exclusive locking）。 如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。 具体响应方式由开发者根据实际需要决定。 如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。 其间如果有其他对该记录做修改或加排他锁的操作，都会等待我们解锁或直接抛出异常。 MySQL InnoDB中使用悲观锁 要使用悲观锁，我们必须关闭mysql数据库的自动提交属性，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新操作后，MySQL会立刻将结果进行提交。set autocommit=0; //0.开始事务 begin;/begin work;/start transaction; (三者选一就可以) //1.查询出商品信息 select status from t_goods where id=1 for update; //2.根据商品信息生成订单 insert into t_orders (id,goods_id) values (null,1); //3.修改商品status为2 update t_goods set status=2; //4.提交事务 commit;/commit work; 以上，在对id = 1的记录修改前，先通过for update的方式进行加锁，然后再进行修改。这就是比较典型的悲观锁策略。 如果以上修改库存的代码发生并发，同一时间只有一个线程可以开启事务并获得id=1的锁，其它的事务必须等本次事务提交之后才能执行。这样我们可以保证当前的数据不会被其它事务修改。 上面的查询语句中，我们使用了select…for update的方式，这样就通过开启排他锁的方式实现了悲观锁。此时在t_goods表中，id为1的 那条数据就被我们锁定了，其它的事务必须等本次事务提交之后才能执行。这样我们可以保证当前的数据不会被其它事务修改。 上面我们提到，使用select…for update会把数据给锁住，不过我们需要注意一些锁的级别，MySQL InnoDB默认行级锁。行级锁都是基于索引的，如果一条SQL语句用不到索引是不会使用行级锁的，会使用表级锁把整张表锁住，这点需要注意。 优点与不足 悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证。但是在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增加产生死锁的机会；另外，在只读型事务处理中由于不会产生冲突，也没必要使用锁，这样做只能增加系统负载；还有会降低了并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数 乐观锁 在关系数据库管理系统里，乐观并发控制（又名“乐观锁”，Optimistic Concurrency Control，缩写“OCC”）是一种并发控制的方法。它假设多用户并发的事务在处理时不会彼此互相影响，各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务又修改了该数据。如果其他事务有更新的话，正在提交的事务会进行回滚。乐观事务控制最早是由孔祥重（H.T.Kung）教授提出。 乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。 相对于悲观锁，在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。一般的实现乐观锁的方式就是记录数据版本。 数据版本,为数据增加的一个版本标识。当读取数据时，将版本标识的值一同读出，数据每更新一次，同时对版本标识进行更新。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的版本标识进行比对，如果数据库表当前版本号与第一次取出来的版本标识值相等，则予以更新，否则认为是过期数据。 实现数据版本有两种方式，第一种是使用版本号，第二种是使用时间戳。 使用版本号实现乐观锁 使用版本号时，可以在数据初始化时指定一个版本号，每次对数据的更新操作都对版本号执行+1操作。并判断当前版本号是不是该数据的最新的版本号。 1.查询出商品信息 select (status,status,version) from t_goods where id=#{id} 2.根据商品信息生成订单 3.修改商品status为2 update t_goods set status=2,version=version+1 where id=#{id} and version=#{version}; 以上SQL其实还是有一定的问题的，就是一旦发上高并发的时候，就只有一个线程可以修改成功，那么就会存在大量的失败。 对于像淘宝这样的电商网站，高并发是常有的事，总让用户感知到失败显然是不合理的。所以，还是要想办法减少乐观锁的粒度的。 有一条比较好的建议，可以减小乐观锁力度，最大程度的提升吞吐率，提高并发能力！如下： //修改商品库存 update item set quantity=quantity - 1 where id = 1 and quantity - 1 > 0 以上SQL语句中，如果用户下单数为1，则通过quantity – 1 > 0的方式进行乐观锁控制。 以上update语句，在执行过程中，会在一次原子操作中自己查询一遍quantity的值，并将其扣减掉1。 高并发环境下锁粒度把控是一门重要的学问，选择一个好的锁，在保证数据安全的情况下，可以大大提升吞吐率，进而提升性能。 优点与不足 乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。 如何选择 在乐观锁与悲观锁的选择上面，主要看下两者的区别以及适用场景就可以了。 1、乐观锁并未真正加锁，效率高。一旦锁的粒度掌握不好，更新失败的概率就会比较高，容易发生业务失败。 2、悲观锁依赖数据库锁，效率低。更新失败的概率比较低。 随着互联网三高架构（高并发、高性能、高可用）的提出，悲观锁已经越来越少的被使用到生产环境中了，尤其是并发量比较大的业务场景。 参考资料 维基百科-乐观并发控制 维基百科-悲观并发控制 mysql悲观锁总结和实践 mysql乐观锁总结和实践 乐观锁与悲观锁
-
MySql的InnoDB引擎的索引知识小结 InnoDB存储引擎支持两种常见的索引：B+树索引、Hash索引。 B+树索引是目前关系型数据库系统中最常见、最有效的索引。 B+树中的B代表的不是二叉（binary），而是平衡（balance），所以，B+树是平衡树并不是二叉树。 B+树索引能找到的只是被查找数据行所在的页。然后数据库把页读入内存，再从内存中进行查找，最后得到要查找的数据。 在数据库中，B+树的高度一般在2-3层，也就意味着在查找某一个键所对应的值的时候，大概需要2-3次IO。 数据库中的B+树索引分为聚集索引和非聚集索引（辅助索引） 聚集索引就是按照每张表的主键构造一个B+树，B+树的一个叶子几点中记录着表中一行记录的所有值。只要找到这个叶子节点也就得到了这条记录的所有值。 辅助索引的叶节点中不包含行记录的所有值。只包含一个键值和一个书签（bookmark），书签用于定位与索引对应的数据行。 每张表只能有一个聚集索引，可以有多个辅助索引。 辅助索引通过叶级别的指针获得指向主键的索引，然后再通过聚集索引定位数据行。 对于索引的添加或删除操作，MySql数据库会先创建一张临时表，然后把数据导入临时表中，删除原表，再把临时表名改为原来的表名。所以，增加和删除索引有成本。 当某个字段的取值分布范围比较广的时候（高选择性）适合使用B+树索引。如果某字段只有Y和N两个取值，那么没必要使用索引。 如果要查询的字段具有高选择性，但是本次检索的数据占总数据量的一半以上时，MySql就不会使用索引进行查询。 联合索引是指对表上的多个列做索引。 如果有一个3列索引(col1,col2,col3)，则已经对(col1)、(col1,col2)、(col1,col3)和(col1,col2,col3)上建立了索引；这就是最左前缀原则。 搜索的索引列，不一定是所要选择的列。换句话说，最适合索引的列是出现在 WHERE 子句中的列，或连接子句中指定的列，而不是出现在 SELECT 关键字后的选择列表中的列。 使用短索引。如果对字符串列进行索引，应该指定一个前缀长度,只要有可能就应 该这样做。例如，如果有一个 CHAR(200)列,如果在前 10 个或 20 个字符内，多数值是惟一的，那么就不要对整个列进行索引。 不要过度索引。 Hash只用于使用=或操作符的等式比较。 B+树索引,当使用>、=、
-
数据库的锁机制 数据库的读现象浅析中介绍过，在并发访问情况下，可能会出现脏读、不可重复读和幻读等读现象，为了应对这些问题，主流数据库都提供了锁机制，并引入了事务隔离级别的概念。 并发控制 在计算机科学，特别是程序设计、操作系统、多处理机和数据库等领域，并发控制（Concurrency control）是确保及时纠正由并发操作导致的错误的一种机制。 数据库管理系统（DBMS）中的并发控制的任务是确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性。下面举例说明并发操作带来的数据不一致性问题： 现有两处火车票售票点，同时读取某一趟列车车票数据库中车票余额为 X。两处售票点同时卖出一张车票，同时修改余额为 X -1写回数据库，这样就造成了实际卖出两张火车票而数据库中的记录却只少了一张。 产生这种情况的原因是因为两个事务读入同一数据并同时修改，其中一个事务提交的结果破坏了另一个事务提交的结果，导致其数据的修改被丢失，破坏了事务的隔离性。并发控制要解决的就是这类问题。 封锁、时间戳、乐观并发控制(乐观锁)和悲观并发控制（悲观锁）是并发控制主要采用的技术手段。 锁 当并发事务同时访问一个资源时，有可能导致数据不一致，因此需要一种机制来将数据访问顺序化，以保证数据库数据的一致性。锁就是其中的一种机制。 在计算机科学中，锁是在执行多线程时用于强行限制资源访问的同步机制，即用于在并发控制中保证对互斥要求的满足。 锁的分类(oracle) 一、按操作划分，可分为DML锁、DDL锁 二、按锁的粒度划分，可分为表级锁、行级锁、页级锁（mysql） 三、按锁级别划分，可分为共享锁、排他锁 四、按加锁方式划分，可分为自动锁、显示锁 五、按使用方式划分，可分为乐观锁、悲观锁 DML锁（data locks，数据锁），用于保护数据的完整性，其中包括行级锁(Row Locks (TX锁))、表级锁(table lock(TM锁))。 DDL锁（dictionary locks，数据字典锁），用于保护数据库对象的结构，如表、索引等的结构定义。其中包排他DDL锁（Exclusive DDL lock）、共享DDL锁（Share DDL lock）、可中断解析锁（Breakable parse locks）
-
数据库的读现象浅析 “读现象”是多个事务并发执行时，在读取数据方面可能碰到的状况。先了解它们有助于理解各隔离级别的含义。其中包括脏读、不可重复读和幻读。 脏读 脏读又称无效数据的读出，是指在数据库访问中，事务T1将某一值修改，然后事务T2读取该值，此后T1因为某种原因撤销对该值的修改，这就导致了T2所读取到的数据是无效的。 脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交(commit)到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是脏数据，依据脏数据所做的操作可能是不正确的。 举例说明： 在下面的例子中，事务2修改了一行，但是没有提交，事务1读了这个没有提交的数据。现在如果事务2回滚了刚才的修改或者做了另外的修改的话，事务1中查到的数据就是不正确的了。 事务一 事务二 /* Query 1 */SELECT age FROM users WHERE id = 1;/* will read 20 */ /* Query 2 */UPDATE users SET age = 21 WHERE id = 1;/* No commit here */ /* Query 1 */SELECT age FROM users WHERE id = 1;/* will read 21 */ ROLLBACK;/* lock-based DIRTY READ */ 在这个例子中，事务2回滚后就没有id是1，age是21的数据了。所以，事务一读到了一条脏数据。 不可重复读 不可重复读，是指在数据库访问中，一个事务范围内两个相同的查询却返回了不同数据。这是由于查询时系统中其他事务修改的提交而引起的。比如事务T1读取某一数据，事务T2读取并修改了该数据，T1为了对读取值进行检验而再次读取该数据，便得到了不同的结果。 一种更易理解的说法是：在一个事务内，多次读同一个数据。在这个事务还没有结束时，另一个事务也访问该同一数据。那么，在第一个事务的两次读数据之间。由于第二个事务的修改，那么第一个事务读到的数据可能不一样，这样就发生了在一个事务内两次读到的数据是不一样的，因此称为不可重复读，即原始读取不可重复。 举例说明： 在基于锁的并发控制中“不可重复读(non-repeatable read)”现象发生在当执行SELECT 操作时没有获得读锁(read locks)或者SELECT操作执行完后马上释放了读锁； 多版本并发控制中当没有要求一个提交冲突的事务回滚也会发生“不可重复读(non-repeatable read)”现象。 事务一 事务二 /* Query 1 */SELECT * FROM users WHERE id = 1; /* Query 2 */UPDATE users SET age = 21 WHERE id = 1;COMMIT;/* in multiversion concurrencycontrol, or lock-based READ COMMITTED */ /* Query 1 */SELECT * FROM users WHERE id = 1;COMMIT; /*lock-based REPEATABLE READ */ 在这个例子中，事务2提交成功，因此他对id为1的行的修改就对其他事务可见了。但是事务1在此前已经从这行读到了另外一个“age”的值。 幻读 幻读是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，比如这种修改涉及到表中的“全部数据行”。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入“一行新数据”。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样.一般解决幻读的方法是增加范围锁RangeS，锁定检锁范围为只读，这样就避免了幻读。 幻读(phantom read)”是不可重复读(Non-repeatable reads)的一种特殊场景：当事务没有获取范围锁的情况下执行SELECT … WHERE操作可能会发生“幻影读(phantom read)”。 举例说明： 当事务1两次执行SELECT … WHERE检索一定范围内数据的操作中间，事务2在这个表中创建了(如INSERT)了一行新数据，这条新数据正好满足事务1的“WHERE”子句。 事务一 事务二 /* Query 1 */SELECT * FROM usersWHERE age BETWEEN 10 AND 30; /* Query 2 */INSERT INTO users VALUES ( 3, 'Bob', 27 );COMMIT; /* Query 1 */SELECT * FROM usersWHERE age BETWEEN 10 AND 30; 在这个例子中，事务一执行了两次相同的查询操作。但是两次操作中间事务二向数据库中增加了一条符合事务一的查询条件的数据，导致幻读。 解决方案 要想解决脏读、不可重复读、幻读等读现象，那么就需要提高事务的隔离级别。但与此同时，事务的隔离级别越高，并发能力也就越低。所以，还需要读者根据业务需要进行权衡。 参考资料 维基百科
-
InnoDB为什么不用跳表，Redis为什么不用B+树？ Innodb是MySQL的执行引擎，MySQL是一种关系型数据库，而Redis是一种非关系型数据库。这两者之间比较大的区别是：关系型数据库以表的形式进行存储数据，而非关系型数据库以Key-value的形式存储数据。 在InnoDB中，索引是采用B+树实现的，在Redis中，ZSET是采用跳表（不只是跳表）实现的，无论是B+树，还是跳表，都是性能很好的数据结构，那么，为什么InnoDB为什么不用跳表，Redis为什么不用B+树？ 我们都知道，MySQL是基于磁盘存储的，Redis是基于内存存储的。 而之所以Innodb用B+树，主要是因为B+树是一种磁盘IO友好型的数据结构，而Redis使用跳表，是因为跳表则是一种内存友好型的数据结构。 B+树磁盘友好？ 首先，B+树的叶子节点形成有序链表，可以方便地进行范围查询操作。对于磁盘存储来说，顺序读取的效率要高于随机读取，因为它可以充分利用磁盘预读和缓存机制，减少磁盘 I/O 的次数。 其次，由于B+树的节点大小是固定的，因此可以很好地利用磁盘预读特性，一次性读取多个节点到内存中，这样可以减少IO操作次数，提高查询效率。 还有就是，B+树的叶子节点都存储数据，而非数据和指针混合，所以叶子节点的大小是固定的，而且节点的大小一般都会设置为一页的大小，这就使得节点分裂和合并时，IO操作很少，只需读取和写入一页。 所以，B+树在设计上考虑了磁盘存储的特点和性能优化，我曾经分析过，当Innodb中存储2000万数据的时候，只需要3次磁盘就够了。（具体分析在我出的面试宝典中。） 而跳表就不一样了，跳表的索引节点通过跳跃指针连接，形成多级索引结构。这导致了跳表的索引节点在磁盘上存储时会出现数据分散的情况，即索引节点之间的物理距离可能较远。对于磁盘存储来说，随机访问分散的数据会增加磁头的寻道时间，导致磁盘 I/O 的性能下降。 为啥Redis用跳表 既然B+树这么多优点，为啥Redis要用跳表实现ZSET呢（不只是跳表，详见下面链接）？而不是B+树呢？ 主要是因为Redis是一种基于内存的数据结构。他其实不需要考虑磁盘IO的性能问题，所以，他完全可以选择一个简单的数据结构，并且性能也能接受的 ，那么跳表就很合适。 因为跳表相对于B+树来说，更简单。相比之下，B+树作为一种复杂的索引结构，需要考虑节点分裂和合并等复杂操作，增加了实现和维护的复杂度。 而且，Redis的有序集合经常需要进行插入、删除和更新操作。跳表在动态性能方面具有良好的表现，特别是在插入和删除操作上。相比之下，B+树的插入和删除需要考虑平衡性，所以还是成本挺高的。 总结 以上，就是关于《InnoDB为什么不用跳表，Redis为什么不用B+树？》这个问题的我的一些理解，其实这个问题想要回答好还挺难的。 首先要知道为啥Innodb使用红黑树，其次还要了解Redis中的Zset数据结构，还需要知道跳表的原理。 和这个问题类似的问题还有： Innodb为什么不用红黑树？Innodb为什么不用B树？Redis的ZSet中zipList和skipList是什么？为什么Redis 7.0中使用ListPack实现ZSet？ 本文内容节选自我最近出的Java面试宝典，上面的这几个问题，在宝典中也都能找到答案，类似的问题及答案还有600多道题。 我们会持续更新内容，争取做到全网最新、最全、最准确的Java后端面试宝典。 之前在我抖音号上面卖了几天。现在已经卖了几百份了，而且，没有中差评！ 因为要涨价了，所以，在公众号也发一下，弄了个微信小商店上面的链接，这个课程，是在线文档，永久更新的，并且没有时间限制。不需要你续费、也不需要二次消费。 大家可以通过下方二维码扫码购买，下单后根据短信提示申请权限并联系客服审批即可！
