❶ mysql的事务四个特性以及事务的四个隔离级别
分别是原子性、一致性、隔离性、持久性。
原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。
一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。举例来说，假设用户A和用户B两者的钱加起来一共是1000，那么不管A和B之间如何转账、转几次账，事务结束后两个用户的钱相加起来应该还得是1000，这就是事务的一致性。
隔离性是当多个用户并发访问数据库时，比如同时操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。关于事务的隔离性数据库提供了多种隔离级别，稍后会介绍到。
持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。例如我们在使用JDBC操作数据库时，在提交事务方法后，提示用户事务操作完成，当我们程序执行完成直到看到提示后，就可以认定事务已经正确提交，即使这时候数据库出现了问题，也必须要将我们的事务完全执行完成。否则的话就会造成我们虽然看到提示事务处理完毕，但是数据库因为故障而没有执行事务的重大错误。这是不允许的。
在数据库操作中，在并发的情况下可能出现如下问题：
正是为了解决以上情况，数据库提供了几种隔离级别。
数据库事务的隔离级别有4个，由低到高依次为Read uncommitted(未授权读取、读未提交)、Read committed（授权读取、读提交）、Repeatable read（可重复读取）、Serializable（序列化），这四个级别可以逐个解决脏读、不可重复读、幻象读这几类问题。
虽然数据库的隔离级别可以解决大多数问题，但是灵活度较差，为此又提出了悲观锁和乐观锁的概念。
悲观锁，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度。因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制。也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统的数据访问层中实现了加锁机制，也无法保证外部系统不会修改数据。
商品t_items表中有一个字段status，status为1代表商品未被下单，status为2代表商品已经被下单（此时该商品无法再次下单），那么我们对某个商品下单时必须确保该商品status为1。假设商品的id为1。
如果不采用锁，那么操作方法如下：
但是上面这种场景在高并发访问的情况下很可能会出现问题。例如当第一步操作中，查询出来的商品status为1。但是当我们执行第三步Update操作的时候，有可能出现其他人先一步对商品下单把t_items中的status修改为2了，但是我们并不知道数据已经被修改了，这样就可能造成同一个商品被下单2次，使得数据不一致。所以说这种方式是不安全的。
在上面的场景中，商品信息从查询出来到修改，中间有一个处理订单的过程，使用悲观锁的原理就是，当我们在查询出t_items信息后就把当前的数据锁定，直到我们修改完毕后再解锁。那么在这个过程中，因为t_items被锁定了，就不会出现有第三者来对其进行修改了。需要注意的是，要使用悲观锁，我们必须关闭mysql数据库的自动提交属性，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新操作后，MySQL会立刻将结果进行提交。我们可以使用命令设置MySQL为非autocommit模式： set autocommit=0;
设置完autocommit后，我们就可以执行我们的正常业务了。具体如下：
上面的begin/commit为事务的开始和结束，因为在前一步我们关闭了mysql的autocommit，所以需要手动控制事务的提交。
上面的第一步我们执行了一次查询操作： select status from t_items where id=1 for update; 与普通查询不一样的是，我们使用了 select…for update 的方式，这样就通过数据库实现了悲观锁。此时在t_items表中，id为1的那条数据就被我们锁定了，其它的事务必须等本次事务提交之后才能执行。这样我们可以保证当前的数据不会被其它事务修改。需要注意的是，在事务中，只有 SELECT ... FOR UPDATE 或 LOCK IN SHARE MODE 操作同一个数据时才会等待其它事务结束后才执行，一般 SELECT ... 则不受此影响。拿上面的实例来说，当我执行 select status from t_items where id=1 for update; 后。我在另外的事务中如果再次执行 select status from t_items where id=1 for update; 则第二个事务会一直等待第一个事务的提交，此时第二个查询处于阻塞的状态，但是如果我是在第二个事务中执行 select status from t_items where id=1; 则能正常查询出数据，不会受第一个事务的影响。
使用 select…for update 会把数据给锁住，不过我们需要注意一些锁的级别，MySQL InnoDB默认Row-Level Lock，所以只有“明确”地指定主键或者索引，MySQL 才会执行Row lock (只锁住被选取的数据) ，否则MySQL 将会执行Table Lock (将整个数据表单给锁住)。举例如下：
1、 select * from t_items where id=1 for update;
这条语句明确指定主键（id=1），并且有此数据（id=1的数据存在），则采用row lock。只锁定当前这条数据。
2、 select * from t_items where id=3 for update;
这条语句明确指定主键，但是却查无此数据，此时不会产生lock（没有元数据，又去lock谁呢？）。
3、 select * from t_items where name='手机' for update;
这条语句没有指定数据的主键，那么此时产生table lock，即在当前事务提交前整张数据表的所有字段将无法被查询。
4、 select * from t_items where id>0 for update; 或者 select * from t_items where id>1 for update; （注：>在SQL中表示不等于）
上述两条语句的主键都不明确，也会产生table lock。
5、 select * from t_items where status=1 for update; （假设为status字段添加了索引）
这条语句明确指定了索引，并且有此数据，则产生row lock。
6、 select * from t_items where status=3 for update; （假设为status字段添加了索引）
这条语句明确指定索引，但是根据索引查无此数据，也就不会产生lock。
乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以只会在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则返回用户错误的信息，让用户决定如何去做。实现乐观锁一般来说有以下2种方式：
❷ 在标准sql中，事务的隔离级别包含哪些
spring的事务处理主要是依靠AOP实现的，这个没什么好说的随便搜索一下，网上很多示例。隔离级别是针对并发事务而言的，单个事务的处理很简单不多说。并发事务的处理则比较复杂，因为往往一条数据是跨事务的，这会造成许多不可预知的后果。一般来说，系统执行并发事务时，会把当前在执行的事务独立起来，也就是和其他事务进行隔离。好像系统中只有这一个事务，其他事务不存在一样。这也就是完全隔离，即系统中只运行单位时间内，最多只有一个事务在执行，其他事务要等到该事务执行完毕之后才能执行，这在现实中基本是不可行的，比如，你要更新你的QQ用户信息，那么就是说，在你更新的这段时间内，其他的用户是无法更新他的用户信息的。举个深动的例子，把事务比作一条在公路上奔跑的汽车，完全隔离，就像是，在汽车从公路一头到另一头这段时间内，公路上不允许有其他的汽车，这样做当然可以完全避免车祸，也就是数据跨事务带来的隐患风险，但是带来了巨大的效率问题，那么如果同时在公路上让多辆汽车行驶会造成什么情况呢。具体来说有一下几种：更新丢失（LostUpdate）：两个事务都企图去更新一行数据，导致事务抛出异常退出，两个事务的更新都白费了。脏数据（DirtyRead）：如果第二个应用程序使用了第一个应用程序修改过的数据，而这个数据处于未提交状态，这时就会发生脏读。第一个应用程序随后可能会请求回滚被修改的数据，从而导致第二个事务使用的数据被损坏，即所谓的“变脏”。不可重读（UnrepeatableRead）：一个事务两次读同一行数据，可是这两次读到的数据不一样，就叫不可重读。如果一个事务在提交数据之前，另一个事务可以修改和删除这些数据，就会发生不可重读。幻读（PhantomRead）：一个事务执行了两次查询，发现第二次查询结果比第一次查询多出了一行，这可能是因为另一个事务在这两次查询之间插入了新行。以上就是并行事务处理时常遇到的大致问题。针对这些问题，提出了几个不同的事务隔离级别，适应特定的环境需要。具体是：读操作未提交（ReadUncommitted）：说明一个事务在提交前，其变化对于其他事务来说是可见的。这样脏读、不可重读和幻读都是允许的。当一个事务已经写入一行数据但未提交，其他事务都不能再写入此行数据；但是，任何事务都可以读任何数据。这个隔离级别使用排写锁实现。读操作已提交（ReadCommitted）：读取未提交的数据是不允许的，它使用临时的共读锁和排写锁实现。这种隔离级别不允许脏读，但不可重读和幻读是允许的。可重读（RepeatableRead）：说明事务保证能够再次读取相同的数据而不会失败。此隔离级别不允许脏读和不可重读，但幻读会出现。可串行化（Serializable）：提供最严格的事务隔离。这个隔离级别不允许事务并行执行，只允许串行执行。这样，脏读、不可重读或幻读都可发生
❸ Windows Server 2016第三版技术预览带来了哪些新特性
随着Windows Server 2016和System Center2016第 三版技术预览的发布，我们也迎来了全新的里程碑。借助这两个分别针对混合云和数据中心的解决方案的推出，微软希望能够帮助用户将云计算的灵活性引入企业。 对于微软来说，这些里程碑式的产品在公司发展历程中扮演了重要角色，它让我们有机会了解各个用户群体的看法。我们也希望用户能够从一开始就了解我们推出此 产品的初衷、熟悉新的功能，并了解这项新技术将如何改进你的业务。
对于用户来说，此次的亮点是首次发布的Windows Server容器。这是将容器技术带入WindowsServer生态系统的第一步，我们对随之而来的可能性感到非常兴奋。你可能已经看到容器技术的发展势头，这种新技术可以简化应用的开发与部署。我们致力于让容器技术成为现代应用平台的一部分，并将其整合在2016年推出的数据中心解决方案中，提供给我们的客户。您可以通过MikeNeil的博客了解有关于容器技术创新的更多信息。
容器仅仅是Windows Server和SystemCenter技术预览版众多新特性中的一个。除此之外，我们还增强了上一个预览版中的功能，并添加了一些新的特性，供你第一时间进行评估。
Nano Server
作为最小的内存部署选项，就像在技术预览版2阶段一样，Nano Server可以被安装在物理主机或虚拟机上。新的EmergencyManagement Console让用户可以在NanoServer控制台中直接查看和修复网络配置。此外，我们还提供PowerShell脚本用于创建一个运行NanoServer的Azure虚拟机。从应用的角度来说，你现在可以使用CoreCLR运行ASP.Netv5应用。总而言之，我们增加了重大功能以扩展Nano Server能力，而这一切的更新都建立在维持原有内存占用的基础之上。
软件定义网络
在第三版技术预览中，你会发现绝大多数网络功能是新增的。我们引入了用于编程政策的可扩展网络控制器、用于高可用性和高性能的L4负载均衡器、用于混合连接的增强网关，以及融合了RDMA流量和租户流量的底层网络结构。在此次发布的预览版中，你将首次体验到我们在Azure中使用的核心网络功能套件和SDN架构。
安全
此次发布的预览版增加了对于Hyper-V的投入：包括某些用于下一版本的安全创新。虚拟机隔离是我们承诺的核心，即帮助你保护共享环境中的资源。现在，你可以通过一个署名模板测试创建一个屏蔽虚拟机，以及该新屏蔽虚拟机的其他功能。你还可以发现WindowsServer扮演的全新角色——Host Guardian Service，管理员可以识别合法主机。
工作负载支持
● 用于增强关键工作复杂支持的附加特性和功能包括：
● 借助拥有OpenGL支持的Remote Desktop Services提高应用兼容性。
● 借助Storage Replica，对面向延展集群的站点感知而改进业务连续性场景。
● 通过为SQL Server集群删除特定域容器而增加灵活性。
管理
在System Center 2016第三版技术预览版中，增强的特性简化了WindowsServer中新功能的管理。包括对Virtual Machine Manager的改进，如支持集群节点的滚动升级，支持NanoServer作为主机和文件服务器。通过轻松管理隔离虚拟机和受保护主机，你还可以充分利用我们针对共享环境的安全增强功能。在存储方面，你会看到改进的功能，以保持满足预期的端对端服务质量（QoS）和更快速的数据（使用存储分层）检索。在OperationsManager中，我们则侧重于通过管理包的可发现性，和使用PowerShel自动化维护窗口的能力，来提升用户体验。
此外，我们还发布了面向Windows 10客户端的Remote Server AdministrationTools（RSAT），实现对Windows Server 2016技术预览版、Windows Server 2012R2和Windows Server 2012的远程管理。
更多的新特性待你评估，详情可查看Experience Guides；我们还欢迎各位参加我们的User Voice计划，参与整个开发过程。目前Windows Server 2016第三版技术预览及System Center 2016第三版技术预览都已经开放下载。期待来自你的建议。
注意：以上提到的软件、特性及功能均基于预览版，实际发布时可能会有所不同。
❹ 用sql数据库做个小程序，实现数据隔离，怎么控制
看了你的需求，首页区分下概念，分清哪些是数据库中的设置的，哪些是在程序中设置的。
第一个问题：
连接数据库时的登录名：就是登陆Sql Server的账号（sa为默认的最高权限）；在sql中称为登陆名，可以在sql中新建登陆名，该登陆名可以设置sql的登陆权限，在新建登陆名时用户映射中，设置该登陆名可以访问的数据库名。登陆名包含了登陆权限（就是获取数据库权限的用户名）。登陆名下包含了服务器角色（批处理权限的角色）信息，一般有sysadmin（sa）、public（新建的、默认）等。
上述用户是sql中设置的信息，与程序无关。而程序使用的登陆用户名是在sql中新建一个数据库（AA），然后在数据库中在新建一张用户表（User），即你所说的用户表包含了序号（ID）、用户名（UID）、密码（PWD）、身份（LOGIN）4个字段。程序的登陆名只是User表中的一个字段（UID）。
第二个问题：
首要要更正你的观点，既然是程序里面要在登陆时要实现不同的身份查看不同的数据，那么所有的问题都由程序来做，与数据库无关。只不过在数据库AA里建立不同的表，存放不同的数据。因此总体设计如下：
1、建立sql数据库连接登陆名，只需要一个，用默认的sa也可以
2、建立数据库AA
3、建立各数据表。包括User表，User表中的用户名（UID）即程序登陆用户名
程序设计
4、程序建立与sql server的连接（即用1中新建的，sa也可以）
5、制作登陆验证程序。首页验证UID与PWD是否匹配，其次根据不同的LOGIN跳转不同的界面
6、在各自不同的界面调用所需要的数据
希望你能看明白！
❺ 数据库的事务隔离级别,以及怎么解决这些问题
SQL标准定义了四种隔离级别:
目前mysql默认使用可重复读隔离级别.
❻ 标准SQL规范中定义的四个事务隔离级别
在标准SQL规范中，定义了4个事务隔离级别，不同的隔离级别对事务的处理不同:
◆未授权读取(Read Uncommitted)：允许脏读取，但不允许更新丢失。如果一个事务已经开始写数据，则另外一个数据则不允许同时进行写操作，但允许其他事务读此行数据。该隔离级别可以通过“排他写锁”实现。
◆授权读取(Read Committed)：允许不可重复读取，但不允许脏读取。这可以通过“瞬间共享读锁”和“排他写锁”实现。读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访问该行。
◆可重复读取(Repeatable Read)：禁止不可重复读取和脏读取，但是有时可能出现幻影数据。这可以通过“共享读锁”和“排他写锁”实现。读取数据的事务将会禁止写事务(但允许读事务)，写事务则禁止任何其他事务。
◆序列化(Serializable)：提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个地执行，但不能并发执行。如果仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。
隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed，它能够避免脏读取，而且具有较好的并发性能。尽管它会导致不可重复读、虚读和第二类丢失更新这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。
通过前面的介绍已经知道，通过选用不同的隔离等级就可以在不同程度上避免前面所提及的在事务处理中所面临的各种问题。所以，数据库隔离级别的选取镇此就显得尤为重要，在选取数据库的隔离级别时，应该注意以下几个处理的原则：
首先，必须排除“未授权读取”，因为在多个事务之间使用它将会是非常危险的。事务的回滚操作或失败将会影响到其他并发事务。第一个事务的回滚将会完全将其他事务的操作清除，甚至使数据库处在一个不一致的状态。很可能一个已回滚为结束的事务对数据的修改最后却修改提交了，因为“未授权读取”允许其他事务读取数据，最后整个错误状态在其他事务之间传播开来。
其次，绝大部分应用都无须使用“序列化御液迅”隔离(一般来说，读取幻影数据并不是一个问题)，此隔离级别也难以测量。目前使用序列化隔离的应用中，一般都使用悲观锁，这样强行使所有事务都序列化执行。
剩下的也就是在“授权读取”和“可重复读取”之间选择了。我们先考虑可重复读取。如果所有的数据访问都是在统一的原子数据库事务中，此隔离级别将消除一个事务在另外一个并发事务过程中覆盖数据的可能性(第二个事务更新丢失问题)。这是一个非常重要的问题，但是使用可重复读取并不是解决问题的途径。
假设使用了“版本数据”，Hibernate会自动使用版本数据。Hibernate的一级Session缓存和版本数据已经为你提供了“可重复读取隔离”绝大部分的特性。特别是，版本数据可以防止二次更新丢失的问题，一级Session缓存可以保证持久载入数据的状态与其他事务对数据的修改隔离开来，因此如果使用对所有的数据库事务采用授权读取隔离和版本数据是行得通的。
“可重复读取”为数据库查询提供了更好的效率(仅对那些长时间的数据库事务)，但是由于幻影读取依然存在，因此没必要使用它(对于Web应用来说，一般也很少在一个数据库事务中对同一个表查询两次)。
也可以同时考虑选择使用Hibernate的二级缓存，它可以如同底层埋斗的数据库事务一样提供相同的事务隔离，但是它可能弱化隔离。假如在二级缓存大量使用缓存并发策略，它并不提供重复读取语义(例如，后面章节中将要讨论的读写，特别是非严格读写)，很容易可以选择默认的隔离级别：因为无论如何都无法实现“可重复读取”，因此就更没有必要拖慢数据库了。另一方面，可能对关键类不采用二级缓存，或者采用一个完全的事务缓存，提供“可重复读取隔离”。那么在业务中需要使用到“可重复读取”吗?如果你喜欢，当然可以那样做，但更多的时候并没有必要花费这个代价。
❼ sql server 2008 事务 的 隔离性 怎么理解
没什么特殊的地方 开启一个事务,然后执行必要的操作, 最后提交就行了, 出错的地方可以进行回滚 PL/SQL如果没有使用显式事务,它会自动给你添加一个隐式的