MySQL（31）
悲观锁和乐观锁
——《POJOs in Action》读书笔记（一）
1&&&&&&&&事务隔离
事务隔离是数据库提供的功能。
SQL Server通过SET TRANSACTION ISOLATION LEVEL语句设置事务隔离级别：
SET TRANSACTION ISOLATION LEVEL
&&&&{ READ UNCOMMITTED
&&&&| READ COMMITTED
&&&&| REPEATABLE READ
&&&&| SNAPSHOT
&&&&| SERIALIZABLE
Read Committed是SQL Server的预设隔离等级。
1.1&&&&&&&&&READ UNCOMMITTED
Read UnCommitted事务可以读取事务已修改，但未提交的的记录。
Read UnCommitted事务会产生脏读（Dirty Read）。
Read UnCommitted事务与select语句加nolock的效果一样，它是所有隔离级别中限制最少的。
1.2&&&&&&&&&READ COMMITTED
Read Committed事务不能读取事务已修改，但未提交的记录。
Read Committed是SQL Server的预设隔离等级。
1.3&&&&&&&&&REPEATABLE READ
Repeatable Read事务不能读取交易已修改，但未提交的记录，并且在事务完成之前，任何其它事务都不能修改目前事务已读取的记录。
其它事务仍可以插入新记录，但必须符合当前事务的搜索条件——这意味着当前事务重新查询记录时，会产生幻读（Phantom Read）。
1.4&&&&&&&&&SNAPSHOT
Snapshot事务中任何语句所读取的记录，都是事务启动时的数据。
这相当于事务启动时，数据库为事务生成了一份专用“快照”。
在当前事务中看到不其它事务在当前事务启动之后所进行的数据修改。
Snapshot事务不会读取记录时要求锁定，读取记录的Snapshot事务不会锁住其它事务写入记录，写入记录的事务也不会锁住Snapshot事务读取数据。
1.5&&&&&&&&&SERIALIZABLE
Serializable事务会产生以下效果：
1.语句无法读取其它事务已修改但未提交的记录。
2.在当前事务完成之前，其它事务不能修改目前事务已读取的记录。
3.在当前事务完成之前，其它事务所插入的新记录，其索引键值不能在当前事务的任何语句所读取的索引键范围中。
Serializable事务与select语句加holdlock的效果一样。
2&&&&&&&&READ COMMITTED&和&REPEATABLE READ
Read Committed&和&Repeatable Read&是最常用的两种事务。
Read Committed&是&SQL Server的默认级别；而&Repeatable Read&比Read Committed&更能保证数据一致性。
2.1&&&&&&&&&特点
Read Committed会阻塞其它事务中的update，但不会阻塞select。
Repeatable Read不但会阻塞其它事务中的update，还会阻塞select。
Read Committed&和&Repeatable Read&的相同点是：都会阻塞其它事务的update语句。
Read Committed&和&Repeatable Read&的不同点是：Read Committed&不会阻塞其它事务的select语句，但Repeatable Read阻塞。
注意，Read Committed&和&Repeatable Read&都是行级锁，它们只会锁住与自己相关的记录。当事务提交之后，阻塞的语句就会继续执行。
2.2&&&&&&&&&理解
2.2.1&&&&&READ COMMITTED
Read Committed&事务的含义是我select出来的记录，别人只能看，不能改（只阻塞别的事务的update）。
Read Committed&的缺点是：无法防止读取不一致和修改丢失。
读取不一致是因为Read Committed&不锁住读取的记录；修改丢失是因为别的事务也能读取当前事务的记录，虽然会阻塞别的事务的update，但在当前事务提交之后，别的事务的update语句会继续执行，进而覆盖上一次事务的结果，导致上一次的修改丢失。
2.2.2&&&&&REPEATABLE READ
Repeatable Read&事务的含义是我select出来的记录，不允许别人看，也不允许别人改（阻塞别的事务select、update），这就意味着我可以在事务中多次select数据，而不用担心出现“脏读”——这就是“可重复读取”的意思。
Repeatable Read&虽然解决了Read Committed&事务的读取不一致和修改丢失的缺点，但它也有缺点（尽管这个缺点Read Committed&也有）：
Repeatable Read&不会阻塞insert和delete，所以会出现“幻读”——两次select的结果不一样。还有，Repeatable Read&占用的资源比Read Committed&大。
3&&&&&&&&在应用程序中设置事务隔离级别
READ COMMITTED&是&Microsoft SQL Server Database Engine&的预设隔离等级。
已指定隔离等级时，在&SQL Server&工作阶段中，所有查询和数据操作语言&(DML)&陈述式的锁定行为都会在此隔离等级运作。此隔离等级会维持有效，直到工作阶段结束或隔离等级设为另一个等级为止。
如果应用程序必须在不同隔离等级操作，可以使用下列方法来设定隔离等级：
l&&&&&&&&&&&执行&SET TRANSACTION ISOLATION LEVEL Transact-SQL&陈述式。
l&&&&&&&&&&&如果&ADO.NET&应用程序使用&System.Data.SqlClient&管理的命名空间，可以使用&SqlConnection.BeginTransaction&方法来指定&IsolationLevel&选项。
l&&&&&&&&&&&使用&ADO&的应用程序可以设定&Autocommit Isolation Levels&属性。
l&&&&&&&&&&&当启动交易时，使用&OLE DB&的应用程序可以将&isoLevel&设为所要的交易隔离等级，以呼叫&ITransactionLocal::StartTransaction。当在自动认可模式中指定隔离等级时，使用&OLE DB&的应用程序可以将&DBPROPSET_SESSION&属性&DBPROP_SESS_AUTOCOMMITISOLEVELS&设为所要的交易隔离等级。
l&&&&&&&&&&&使用&ODBC&的应用程序可以使用&SQLSetConnectAttr&来设定&SQL_COPT_SS_TXN_ISOLATION&属性。
4&&&&&&&&悲观锁
悲观锁是指假设并发更新冲突会发生，所以不管冲突是否真的发生，都会使用锁机制。
悲观锁会完成以下功能：锁住读取的记录，防止其它事务读取和更新这些记录。其它事务会一直阻塞，直到这个事务结束。
悲观锁是在使用了数据库的事务隔离功能的基础上，独享占用的资源，以此保证读取数据一致性，避免修改丢失。
悲观锁可以使用Repeatable Read事务，它完全满足悲观锁的要求。
5&&&&&&&&乐观锁
乐观锁不会锁住任何东西，也就是说，它不依赖数据库的事务机制，乐观锁完全是应用系统层面的东西。
如果使用乐观锁，那么数据库就必须加版本字段，否则就只能比较所有字段，但因为浮点类型不能比较，所以实际上没有版本字段是不可行的。
6&&&&&&&&死锁
当二或多个工作各自具有某个资源的锁定，但其它工作尝试要锁定此资源，而造成工作永久封锁彼此时，会发生死锁。例如：
1.&&&&&&&&&&&事务&A&取得数据列&1&的共享锁定。
2.&&&&&&&&&&&事务B&取得数据列&2&的共享锁定。
3.&&&&&&&&&&&事务A&现在要求数据列&2&的独占锁定，但会被封锁直到事务B&完成并释出对数据列&2&的共享锁定为止。
4.&&&&&&&&&&&事务B&现在要求数据列&1&的独占锁定，但会被封锁直到事务A&完成并释出对数据列&1&的共享锁定为止。
等到事务B&完成后，事务A&才能完成，但事务B&被事务A&封锁了。这个状况也称为「循环相依性」(Cyclic Dependency)。事务A&相依于事务B，并且事务B&也因为相依于事务A&而封闭了这个循环。
例如以下操作就会产生死锁，两个连接互相阻塞对方的update。
begin tran
select * from customers
update customers set CompanyName = CompanyName
waitfor delay '00:00:05'
select * from Employees
–因为Employees被连接2锁住了，所以这里会阻塞。
update Employees set LastName = LastName
commit tran
begin tran
select * from Employees
update Employees set LastName = LastName
waitfor delay '00:00:05'
select * from customers
--因为customers被连接1锁住了，所以这里会阻塞。
update customers set CompanyName = CompanyName
commit tran
SQL Server遇到死锁时会自动杀死其中一个事务，而另一个事务会正常结束（提交或回滚）。
SQL Server对杀死的连接返回错误代码是1205，异常提示是：
Your transaction (process ID #52) was deadlocked on {lock | communication buffer | thRead} resources with another process and has been chosen as the deadlock victim. Rerun your transaction.
除了Read UnCommitted和Snapshot，其它类型的事务都可能产生死锁。
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：390727次
积分：4115
积分：4115
排名：第4294名
原创：53篇
转载：165篇
评论：71条
(1)(1)(2)(4)(4)(5)(8)(6)(2)(1)(1)(3)(7)(5)(15)(11)(8)(6)(6)(7)(2)(7)(14)(17)(11)(7)(10)(8)(6)(18)(5)(6)(6)(1)，产品,架构,数据.
计算机及应用
1、你首先有自己的业务场景，然后才设计数据库；&br&2、你应该衡量自己的业务如何使用数据，那些数据会被更频繁的使用；&br&3、你根据以上的信息进行自己的数据库逻辑/物理设计；&br&4、设计好数据库表后，如果你有经验，应该此时的编程能够配合实现你的应用的功能；&br&5、不断迭代设计，这个过程中，已经在使用真实数据/开发工具 在进行开发、设计了；&br&6、绝大部分情况不需要去验证数据库表是否合理，如果你有经验，你应该关注的是那些数据会被频繁访问，以何种方式访问。然后针对这些进行设计优化
1、你首先有自己的业务场景，然后才设计数据库；2、你应该衡量自己的业务如何使用数据，那些数据会被更频繁的使用；3、你根据以上的信息进行自己的数据库逻辑/物理设计；4、设计好数据库表后，如果你有经验，应该此时的编程能够配合实现你的应用的功能；5、…
你的链接我没看。不能这么比。&br&1、你使用什么产品，取决于你的目的，业务，内存不是选择的产品的主要因素；&br&2、数据库产品有两类，一种基于内存，一种基于磁盘，Redis是基于内存，MongoDB是基于磁盘，Redis本来就必须是全内存，何来占用内存过多一说，你应该看你的数据结构，了解Redis的数据结构，看怎么更高效利用内存你；&br&3、Redis自身是可以限制内存使用的，有参数配置，MongoDB是利用操作系统缓存，也就是他可能会用到操作系统所有内存，这个不是什么占用内存，这个是操作系统的机制，你应该假设vps里的所有内存都是给MongoDB使用的。&br&4、自己学习，用什么产品都可以，但如作为论坛的解决方案，显然MySQL是更合适的。
你的链接我没看。不能这么比。1、你使用什么产品，取决于你的目的，业务，内存不是选择的产品的主要因素；2、数据库产品有两类，一种基于内存，一种基于磁盘，Redis是基于内存，MongoDB是基于磁盘，Redis本来就必须是全内存，何来占用内存过多一说，你应该…
收费工具设计的更好些。推荐三个&br&1、SQLyog（收费）&br&2、MySQL Workbench(官方的免费）&br&3、Toad for MySQL
收费工具设计的更好些。推荐三个1、SQLyog（收费）2、MySQL Workbench(官方的免费）3、Toad for MySQL
&p&我说下通用的一些方法&/p&&p&1、使用数据库自身的特性，在数据库启动参数里配置auto_increment_increment和 auto_increment_offset，我们不推荐这种方式，因为这会导致维护数据库的成本上升。&/p&&p&2、配置一个单独的服务生成全局ID，可以是MySQL，也可以是NoSQL产品，甚至你可以构建自己的专门用来生成唯一ID的服务，为了提高效率，你可以批量获取唯一ID序列。&/p&&p&3、另外一种方式是，通过函数、程序算法或者字段组合生成唯一ID，这种方式，可能有冲突，但是这个冲突的概率可以做到非常小，我们更推荐使用这种方式。&/p&
我说下通用的一些方法1、使用数据库自身的特性，在数据库启动参数里配置auto_increment_increment和 auto_increment_offset，我们不推荐这种方式，因为这会导致维护数据库的成本上升。2、配置一个单独的服务生成全局ID，可以是MySQL，也可以是NoSQL产品，甚…
你的概念不清楚。&br&1、客户端发布命令后,可能有很多事务，任何组合都有可能，数据库系统有一个很重要的功能就是处理并发，也就是资源争用情况下如何更新/提交数据。针对你的情况，如果两个事务同时修改一个记录，可能某个事务提交不了，需要等待资源的释放；&br&2、各种事务级别和你举的例子并没有什么关系。你再具体看看各种事务级别是如何定义的。
你的概念不清楚。1、客户端发布命令后,可能有很多事务，任何组合都有可能，数据库系统有一个很重要的功能就是处理并发，也就是资源争用情况下如何更新/提交数据。针对你的情况，如果两个事务同时修改一个记录，可能某个事务提交不了，需要等待资源的释放；2…
对于Redis这种内存数据库，很少有需要扩展读的，建议在主库性能不够的情况下才考虑读写分离。&br&1，应用侧实现，算法，比如hash。2、proxy
对于Redis这种内存数据库，很少有需要扩展读的，建议在主库性能不够的情况下才考虑读写分离。1，应用侧实现，算法，比如hash。2、proxy
可以设置为RC，可以提高性能。&br&但绝大部分网站使用默认的RR已经够了，你们的访问量很小了。&br&是否提升性能要看你的访问模式，不好简单定量分析。
可以设置为RC，可以提高性能。但绝大部分网站使用默认的RR已经够了，你们的访问量很小了。是否提升性能要看你的访问模式，不好简单定量分析。
问问题的时候，建议限制在一个更小的领域，每一个主题都有许多内容，建议先自己一个一个实施下，看每个主题有哪些策略可用。
问问题的时候，建议限制在一个更小的领域，每一个主题都有许多内容，建议先自己一个一个实施下，看每个主题有哪些策略可用。
不要绕过数据库的机制直接操作数据库文件。即使证明了一些事情，很可能下个版本也不确保仍然可行的。&br&做DBA永远是安全第一。
不要绕过数据库的机制直接操作数据库文件。即使证明了一些事情，很可能下个版本也不确保仍然可行的。做DBA永远是安全第一。
OCA,OCP，这些教材是最好的系统化学习的方法。&br&待正式从业后，再择机通过OCM认证提高自己。&br&在工作过程中，你自然会有需要去看一些国内专家的书。
OCA,OCP，这些教材是最好的系统化学习的方法。待正式从业后，再择机通过OCM认证提高自己。在工作过程中，你自然会有需要去看一些国内专家的书。
一个优秀的MySQL DBA需要具备一个或者多个背景。你会开发的话，以后的职业道路会宽很多。建议先从研发 或者 应用运维开始。
一个优秀的MySQL DBA需要具备一个或者多个背景。你会开发的话，以后的职业道路会宽很多。建议先从研发 或者 应用运维开始。
互联网业务一般不使用外键。&br&有索引即可。&br&对于高并发的业务，取消外键是可以提高效率的。
互联网业务一般不使用外键。有索引即可。对于高并发的业务，取消外键是可以提高效率的。
我说几句，应该没有，但有一些公司有规模使用的，大公司不一定就能用好产品，有时只是欲罢不能，不好止损是人的天性。&br&1、一个公司可能有几百上千的研发人员，一个很小的项目使用MongoDB也可以说公司有在使用，毕竟这是一个宣传很厉害的产品，人对新潮的东西总是喜欢的，拥抱变化吧:-) ；&br&2、严重的坑是肯定有的，具体的公司名字我就不说了；&br&3、MongoDB出现过的一些运维上的问题，资源使用上的问题，不算致命的，只要你有钱，关键是使用某个产品，根本的出发点还是你要存储什么数据，你的数据是否有关联，是否是独立的，从这点考虑，MongoDB不太可能作为一个公司的主数据库，因为现在的数据基本都是有关系，有意义的。&br&4、MongoDB具备一定的灵活性，但真正的灵活性是在于你的数据库产品能够满足未来不断增加的商业需求，就这点说来，使用MongoDB其实是给自己在挖坑，除非你很对数据有很深刻的理解，严格限制了数据的使用场景和未来的需求。
我说几句，应该没有，但有一些公司有规模使用的，大公司不一定就能用好产品，有时只是欲罢不能，不好止损是人的天性。1、一个公司可能有几百上千的研发人员，一个很小的项目使用MongoDB也可以说公司有在使用，毕竟这是一个宣传很厉害的产品，人对新潮的东西…
可以认为不会修改索引。&br&注：MySQL InnoDB表的非主键索引里存储了主键的值。
可以认为不会修改索引。注：MySQL InnoDB表的非主键索引里存储了主键的值。
Oracle的RAC是从产品层面解决，互联网世界，更多是从架构层面解决的。有读写分离，有垂直/水平拆分，有不同的缓存层次，各种成熟的解决方案都有。&br&可以参考下我的文章 &a href=&/mysql/& class=&internal&&关于MySQL集群的一些看法 - MySQL - 知乎专栏&/a&
Oracle的RAC是从产品层面解决，互联网世界，更多是从架构层面解决的。有读写分离，有垂直/水平拆分，有不同的缓存层次，各种成熟的解决方案都有。可以参考下我的文章
假设url_id是主键， in 列表不要太长，建议小于200. &br&或者不使用in，基于主键，一条一条记录查询，简单的查询往往效率更高，可以获得更高的吞吐。
假设url_id是主键， in 列表不要太长，建议小于200. 或者不使用in，基于主键，一条一条记录查询，简单的查询往往效率更高，可以获得更高的吞吐。
1，NoSQL可以理解为Not Only SQL。 它不是一个产品，而是一组技术和工具的集合，它突破了传统关系数据库的一些限制，提供了一些更好的特性。&br&2，不能说NoSQL产品就是“弱事务性”的，虽然也许你听过/用过的NoSQL产品对事物的支持不太好，或者不支持。&br&3，MongoDB对于事务的支持是不好的，这也不是它的强项，也可以说”弱“&br&4，适用场景每个人都有不同的看法，适用场景这个提法，过分简化了问题，个人认为没有多大意义。
1，NoSQL可以理解为Not Only SQL。 它不是一个产品，而是一组技术和工具的集合，它突破了传统关系数据库的一些限制，提供了一些更好的特性。2，不能说NoSQL产品就是“弱事务性”的，虽然也许你听过/用过的NoSQL产品对事物的支持不太好，或者不支持。3，Mong…
感觉知乎的运营是有问题的。对于海量用户缺乏引导和制定规则的能力。高端用户会不断流失。&br&我从技术领域在这里是得不到什么有益的东西的。有时纯粹出于帮助入门者，会去回答一些问题，但这些问题，完全可以通过其他渠道获得，或者自己看看书就可以了。&br&如果百度知道化，那么迟早被百度知道干死。
感觉知乎的运营是有问题的。对于海量用户缺乏引导和制定规则的能力。高端用户会不断流失。我从技术领域在这里是得不到什么有益的东西的。有时纯粹出于帮助入门者，会去回答一些问题，但这些问题，完全可以通过其他渠道获得，或者自己看看书就可以了。如果百…
1，这种问题不会有人回答的出来，没有人为了你的问题去看这个视频，而且你链接没有给出来；&br&2，我假设你是个初学者，建议直接去论坛上问 apache、php、MySQL，javascript，PHP，Linux有哪些书值得学习更好，这方面有一些公认的好书，哈佛老师仅仅出于教学目的，他所介绍的书有帮助，但是是英文版，而且不如专业人士给你的推荐更契合业内实际情况。&br&3、如果你有心，应可以找到这位老师的电邮，直接去问他也是一种方法。
1，这种问题不会有人回答的出来，没有人为了你的问题去看这个视频，而且你链接没有给出来；2，我假设你是个初学者，建议直接去论坛上问 apache、php、MySQL，javascript，PHP，Linux有哪些书值得学习更好，这方面有一些公认的好书，哈佛老师仅仅出于教学目…
这个要看具体的数据的访问模式，快或者慢不是必然的。&br&-----------------------------&br&基于行 进行数据存放会比基于列慢吗 为什么 ？&br&答：这要看你是如何更新数据的。没有证据证明一条一条记录来修改，列存储会更快，一般来说，基于行的会更快。&br&为什么列存储不适合oltp 呢？&br&答：因为oltp，是大量随机的一行一行的存取数据，如果是一个列存储，那么需要不断的从各个列中取得相应字段，然后组合成一行记录，循环往复，这样的操作效率并不高。&br&&br&实际的列存储产品，有自己的独有的技术，所以我说得不一定准确。
这个要看具体的数据的访问模式，快或者慢不是必然的。-----------------------------基于行 进行数据存放会比基于列慢吗 为什么 ？答：这要看你是如何更新数据的。没有证据证明一条一条记录来修改，列存储会更快，一般来说，基于行的会更快。为什么列存储不…}